问题空间

The Problem Space

在开发解决方案之前，您必须先了解问题所在。DDD 强调需要关注业务问题领域：其术语、软件开发背后的核心原因以及成功对业务的意义。开发团队需要像重视技术专长一样重视领域知识，这对于深入了解问题领域并将大型领域分解为更小的子领域至关重要。

Before you can develop a solution, you must understand the problem. DDD emphasizes the need to focus on the business problem domain: its terminology, the core reasons behind why the software is being developed, and what success means to the business. The need for the development team to value domain knowledge just as much as technical expertise is vital to gain a deeper insight into the problem domain and to decompose large domains into smaller subdomains.

图 I.1展示了本书第一部分将要介绍的 DDD 问题空间的高层概述。

Figure I.1 shows a high-level overview of the problem space of DDD that will be introduced in the first part of this book.

解决方案空间

The Solution Space

当你对问题领域有深入的理解时，DDD 的战略模式可以帮助你实现与问题空间协同的技术解决方案。模式可以保护系统中对产品成功至关重要的核心部分，使其免受通用领域的干扰。隔离集成组件，使得修改这些组件时不会对整个系统产生连锁反应。

When you have a sound understanding of the problem domain, strategic patterns of DDD can help you implement a technical solution in synergy with the problem space. Patterns enable core parts of your system that are crucial to the success of the product to be protected from the generic areas. Isolating integral components allows them to be modified without having a rippling effect throughout the system.

产品中足够复杂或频繁更改的核心部分应该基于模型。DDD 的战术模式以及模型驱动设计将帮助您在代码中创建实用的领域模型。模型是所有领域逻辑的所在地，这些逻辑使您的应用程序能够满足业务用例。模型与技术复杂性相分离，以便业务规则和策略能够不断发展。与问题领域协同的模型将使您的软件具有适应性，并易于其他开发人员和业务专家理解。

Core parts of your product that are sufficiently complex or will frequently change should be based on a model. The tactical patterns of DDD along with Model-Driven Design will help you create a useful model of your domain in code. A model is the home to all of the domain logic that enables your application to fulfill business use cases. A model is kept separate from technical complexities to enable business rules and policies to evolve. A model that is in synergy with the problem domain will enable your software to be adaptable and understood by other developers and business experts.

图 I.2展示了本书第一部分介绍的 DDD 解决方案空间的高级概述。

Figure I.2 shows a high-level overview of the solution space of DDD that is introduced in the first part of this book.

第一部分：领域驱动设计的原则与实践

Part I: The Principles and Practices of Domain-Driven Design

第一部分向您介绍 DDD 的原理和实践。

Part I introduces you to the principles and practices of DDD.

第二部分：战略模式：在有界上下文之间进行通信

Part II: Strategic Patterns: Communicating between Bounded Contexts

第二部分将向您展示如何集成有界上下文，并详细介绍了构建有界上下文的各种选项。此外，还将提供代码示例，详细说明如何与遗留应用程序集成。此外，本文还介绍了跨有界上下文进行通信的技巧。

Part II shows you how to integrate bounded contexts, and offers details on the options open for architecting bounded contexts. Code examples are presented that detail how to integrate with legacy applications. Also included are techniques for communicating across bounded contexts.

第三部分：战术模式：创建有效的领域模型

Part III: Tactical Patterns: Creating Effective Domain Models

第三部分介绍了可用于在代码中构建域模型的设计模式，以及用于持久化模型的模式和用于管理构成模型的域对象的生命周期的模式。

Part III covers the design patterns you can use to build a domain model in code, along with patterns to persist your model and patterns to manage the lifecycles of the domain objects that form your model.

第四部分：高效应用的设计模式

Part IV: Design Patterns for Effective Applications

第四部分展示了利用和保护域模型完整性的应用程序架构设计模式。

Part IV showcases the design patterns for architecting applications that utilize and protect the integrity of your domain model.

没有通用语言创建的代码

Code Created without a Common Language

缺乏对共享语言和问题领域知识的关注，会导致代码库虽然能用，但无法展现业务意图。由于分析模型和代码模型之间的转换成本高昂且容易出错，代码库难以阅读和维护。

A lack of focus on a shared language and knowledge of the problem domain results in a codebase that works but does not reveal the intent of the business. This makes codebases difficult to read and maintain because translations between the analysis model and the code model can be costly and error prone.

未绑定到业务可理解的分析模型的代码会随着时间的推移而性能下降，因此更有可能形成类似于 BBoM 模式的架构。由于翻译成本高昂，如果团队在代码中未充分利用问题领域丰富的词汇，那么在与业务专家协作时，发现新领域概念的机会就会降低。

Code without a binding to an analysis model that the business understands will degrade over time and is therefore more likely to result in an architecture that resembles the BBoM pattern. Due to the cost of translation teams that do not utilize the rich vocabulary of the problem domain in code will decrease their chances of discovering new domain concepts when collaborating with business experts.

缺乏组织

A Lack of Organization

如图 1.2所示，类似 BBoM 的系统的初始版本开发速度很快，而且通常能取得全面的成功，但由于缺乏围绕问题域模型进行应用程序设计的重点，后续的增强工作也因此变得棘手。代码库缺乏与业务行为所需的协同作用，难以管理变更。问题域的复杂性通常与技术解决方案的偶然复杂性交织在一起。

As highlighted in Figure 1.2, the initial incarnation of a system that resembles BBoM is fast to produce and often a well-rounded success, but because there is little focus based on the design of an application around a model of the problem domain, subsequent enhancements are troublesome. The codebase lacks the required synergy with the business behavior to make change manageable. Complexities of the problem domain are often mixed with the accidental complexities of the technical solution.

泥球模式阻碍发展

The Ball of Mud Pattern Stifles Development

继续沿用意大利面条式的架构模式会导致功能增强速度缓慢。当产品的新版本发布时，由于开发人员必须处理难以理解的代码库，这些代码库可能会出现大量错误。随着时间的推移，开发团队会越来越抱怨在这种混乱的环境中工作困难。即使项目增加了资源，开发速度也无法提升到满足业务需求的水平。

Continuing to persist with an architectural spaghetti-like pattern can lead to a sluggish pace of feature enhancement. When newer versions of the product are released, they can be buggy due to the unintelligible mess of the codebase that developers have to deal with. Over time, the development team increasingly complains about the difficulty of working in such a mess. Even if resources are added to the project, velocity cannot be increased to a level that satisfies the business.

最终，恼火之下，令人畏惧的应用程序重写请求被批准了。然而，如果没有充分的谨慎和考量，即使是全新的项目也可能重蹈最初BBoM的覆辙。整个过程可能会让企业感到沮丧，因为他们一开始在功能和交付速度方面获得了丰厚的投资回报 (ROI)，但随着时间的推移，即使投入了额外的资源，产品也未能持续改进以满足他们的需求。最终，BBoM对开发者来说是个坏消息，因为它是一个混乱且容易出错的代码库，你讨厌处理它。这对企业来说也是一个坏消息，因为它降低了他们快速交付商业价值的能力。

In the end, exasperated by the situation, the request for the dreaded application rewrite is granted. Without due care and consideration, however, even the greenfield project can fall foul of the same issues that created the original BBoM. This entire experience can be frustrating for the business that saw a great return on investment (ROI) in terms of features and speed of delivery at the beginning but over time, even with additional investment in resources, did not see the sustained evolution of the product to meet their needs. Ultimately the BBoM is bad news for you as a developer because it’s a messy bug-prone code base that you hate dealing with. And it’s bad news for the business because it reduces their capability to rapidly deliver business value

缺乏对问题领域的关注

A Lack of Focus on the Problem Domain

如果你对所从事的业务领域了解不够，软件项目就会失败。输入并非交付产品的瓶颈；编码是开发过程中比较容易的部分。除了非功能性需求之外，创建并维护一个能够满足业务用例的、有用的领域软件模型才是难点。然而，你对业务领域的理解越深入，当你尝试用软件建模来解决其固有的业务问题时，你就越有能力。

Software projects fail when you don’t understand the business domain you are working within well enough. Typing is not the bottleneck for delivering a product; coding is the easy part of development. Outside of non-functional requirements creating and keeping a useful software model of the domain that can fulfill business-use cases is the difficult part. However, the more you invest in understanding your business domain the better equipped you will be when you are trying to model it in software to solve its inherent business problems.

DDD 的战略模式

The Strategic Patterns of DDD

DDD 的战略模式提炼问题域并塑造应用程序的架构。

The strategic patterns of DDD distil the problem domain and shape the architecture of an application.

将模型与模糊性和损坏隔离开来

Isolate Models from Ambiguity and Corruption

模型位于有界上下文中，该上下文定义了模型的适用性并确保其完整性。较大的模型可以拆分为较小的模型，并在单独的有界上下文中定义，以进一步降低复杂性，尤其是在存在术语歧义或多个团队协作的情况下。

Models sit within a bounded context, which defines the applicability of the model and ensures that its integrity is retained. Larger models can be split into smaller models and defined within separate bounded contexts where ambiguity in terminology exists or where multiple teams are a working in order to further reduce complexity.

有界上下文用于在模型周围形成保护性边界，有助于防止软件演变成 BBoM。这是通过允许整体解决方案的不同模型在明确定义的业务环境中演进，而不会对系统的其他部分产生负面的连锁影响来实现的。模型与基础设施代码隔离，以避免合并技术和业务概念时意外产生的复杂性。有界上下文还可以通过将模型与第三方代码隔离来防止模型的完整性受到破坏。

Bounded contexts are used to form a protective boundary around models that helps to prevent software from evolving into a BBoM. This is achieved by allowing the different models of the overall solution to evolve within well-defined business contexts without having a negative, rippling impact on other parts of the system. Models are isolated from infrastructure code to avoid the accidental complexity of merging technical and business concepts. Bounded contexts also prevent the integrity of models being corrupt by isolating them from third-party code.

比较图1.3和图 1.2。该图展示了如何将 DDD 的战略模式应用于软件，以管理大型问题域并保护其中的离散模型。

Compare the diagram in Figure 1.3 to Figure 1.2. The diagram shows how the strategic patterns of DDD have been applied to the software to manage the large problem domain and protect discrete models within it.

DDD 的战术模式

The Tactical Patterns of DDD

DDD 的战术模式（也称为模型构建块）是一系列模式的集合，有助于为复杂的有界上下文创建有效的模型。战术模式集合中介绍的许多编码模式在 Evans 的著作问世之前就已被广泛采用，并由 Martin Fowler 在《企业应用程序架构模式》和 Erich Gamma 等人在《设计模式：可复用面向对象软件的元素》中进行了分类。这些模式并非适用于所有模型，必须根据其自身特点，结合正确的架构风格来选择。

The tactical patterns of DDD, also known as model building blocks, are a collection of patterns that help to create effective models for complex bounded contexts. Many of the coding patterns presented within the collection of tactical patterns have been widely adopted before Evans’s text and catalogued by the likes of Martin Fowler in Patterns of Enterprise Application Architecture and Erich Gamma, et al. in Design Patterns: Elements of Reusable Object-Oriented Software. These patterns are not applicable to all models, and each must be taken on its own merit with the correct architectural style applied.

问题空间和解决方案空间

The Problem Space and the Solution Space

本节详述的所有模式都有助于管理问题的复杂性（即问题空间），或者管理解决方案的复杂性（即解决方案空间）。如图 1.4所示，问题空间将问题域提炼为更易于管理的子域。DDD 在问题空间中的作用在于揭示哪些部分是重要的，以及应该将精力集中在哪里。下一章我们将更详细地探讨有助于降低问题空间复杂性的模式。

All of the patterns detailed in this section help to manage the complexity of a problem—aka the problem space or they manage complexity in the solution—aka the solution space. The problem space, as shown in Figure 1.4, distils the problem domain into more manageable subdomains. DDD’s impact in the problem space is to reveal what is important and where to focus effort. In the next chapter we will look in more detail on the patterns that can help reduce complexity in the problem space.

DDD 的解决方案方面（如图 1.5所示）涵盖了可以塑造应用程序架构并使其更易于管理的模式。

The solution side of DDD, shown in Figure 1.5, covers patterns that can shape the architecture of your applications and make it easier to manage.

专注于核心领域

Focusing on the Core Domain

DDD 强调需要将大部分精力集中在核心子域上。核心子域是产品成功与否的关键。它是产品的独特卖点，也是产品被开发而非被购买的原因。核心域是产品中能够赋予您竞争优势并为您的业务创造真正价值的领域。让所有团队成员都理解核心域至关重要。

DDD stresses the need to focus the most effort on the core subdomain. The core subdomain is the area of your product that will be the difference between it being a success and it being a failure. It’s the product’s unique selling point, the reason it is being built rather than bought. The core domain is the area of the product that will give you a competitive advantage and generate real value for your business. It is vital that all of the team understand what the core domain is.

通过合作学习

Learning through Collaboration

DDD 强调开发团队与业务专家之间协作的重要性，以便构建有效的模型来解决问题。如果没有业务专家的协作和投入，许多知识共享将无法进行，开发团队也无法对问题领域获得更深入的洞察。同样，通过协作和知识整合，业务部门有机会更深入地了解其领域。

DDD stresses the importance of collaboration between the development teams and business experts to produce useful models to solve problems. Without this collaboration and commitment from the business experts, much of the knowledge sharing will not be able to take place, and development teams will not gain deeper insights into the problem domain. It is also true that, through collaboration and knowledge crunching, the business has the opportunity to learn much more about its domain.

通过探索和实验创建模型

Creating Models through Exploration and Experimentation

DDD 将分析模型和代码模型视为一体。这意味着技术代码模型通过共享 UL 绑定到分析模型。分析模型的突破会导致代码模型的变更。代码模型的重构能够揭示更深入的洞察，这又会反映在分析模型和业务的思维模型中。只有当团队有时间探索模型并对其设计进行实验时，才能取得突破。花时间进行原型设计和实验可以极大地帮助您塑造更好的设计。它还可以揭示糟糕的设计是什么样的。Eric Evans 认为，每一个好的设计都至少有三个糟糕的设计，这将防止团队停留在第一个有用的模型上。

DDD treats the analysis and code models as one. This means that the technical code model is bound to the analysis model through the shared UL. A breakthrough in the analysis model results in a change to the code model. A refactoring in the code model that reveals deeper insight is again reflected in the analysis model and mental models of the business. Breakthroughs only occur when teams are given time to explore a model and experiment with its design. Spending time prototyping and experimenting can go a long way in helping you shape a better design. It can also reveal what a poor design looks like. Eric Evans suggests that for every good design there must be at least three bad ones, this will prevent teams stopping at the first useful model.

沟通

Communication

能够有效地描述用于表示问题域的模型是 DDD 的基础。正因如此，DDD 最重要的一个方面无疑是创建 UL。如果没有共同的语言，业务团队和开发团队之间解决问题的协作将无法有效进行。团队之间在知识研讨中产生的分析和思维模型需要一种共同的语言来将它们与技术实现绑定。如果没有一种有效的方法来在问题域内交流想法和解决方案，设计突破就无法实现。

The ability to effectively describe a model built to represent a problem domain is the foundation of DDD. This is why, without a doubt, the single most important facet of DDD is the creation of the UL. Without a shared language, collaboration between the business and development teams to solve problems would not be effective. Analysis and mental models produced in knowledge-crunching sessions between the teams need a shared language to bind them to a technical implementation. Without an effective way to communicate ideas and solutions within a problem domain, design breakthroughs cannot occur.

正是 UL 的协作和构建，才使得 DDD 如此强大。它能够更好地理解问题域（对于业务和开发团队而言），并且有效沟通。这些关键价值观对项目有着巨大的影响，因为虽然技术框架和方法论很重要，但 DDD 更重视问题域的分析和理解，而这才是最终决定软件产品成功的关键。

It is the collaboration and construction of a UL that makes DDD so powerful. It enables a greater understanding of the problem domain (for the business and the development team) and more effective communication. These key values have a massive impact on projects because while technical frameworks and methodologies are important, DDD places as much, if not, greater importance on the analysis and understanding of the problem domain that ultimately makes software products successful.

理解模型的适用性

Understanding the Applicability of a Model

每个构建的模型在其子领域的上下文中都能被理解，并使用基本概念（UL）进行描述。然而，在许多大型模型中，UL 内部可能存在歧义，组织的不同部门对一个通用术语或概念的理解可能有所不同。DDD 通过确保每个模型都有其自己的、仅在特定上下文中有效的 UL 来解决这个问题。每个上下文定义了一个语言边界；确保模型在特定上下文中可被理解，以避免语言上的歧义。因此，一个具有重叠术语的模型会被划分为两个模型，每个模型在其自身上下文中都有明确的定义。在实现方面，战略模式可以强制执行这些语言边界，使模型能够独立发展。这些战略模式可以生成组织有序的代码，支持更改和重写。

Each model that is built is understood within the context of its subdomain and described using the UL. However, in many large models, there can be ambiguity within the UL, with different parts of an organization having different understandings of a common term or concept. DDD addresses this by ensuring that each model has its own UL that is valid only in a certain context. Each context defines a linguistic boundary; ensuring models are understood in a specific context to avoid ambiguity in language. Therefore a model with overlapping terms is divided into two models, each clearly defined within its own context. On the implementation side, strategic patterns can enforce these linguistic boundaries to enable models to evolve in isolation. These strategic patterns result in organized code that is able to support change and rewriting.

不断发展模型

Constantly Evolving the Model

任何从事复杂系统的开发人员都能编写优秀的代码并维护一段时间。然而，如果源代码和问题领域之间缺乏协同，持续的开发很可能会最终导致代码库难以修改，从而导致 BBoM（复杂领域模型）。DDD 有助于解决这个问题，它强调团队需要持续关注模型对当前问题的实用性。它要求团队在获得领域洞察后，不断改进和简化复杂的领域模型。DDD 仍然不是灵丹妙药，需要专注和持续的知识积累，才能开发出可维护数年而非数月的软件。新的业务案例可能会破坏先前有用的模型，或者可能需要进行更改以使新的或现有的概念更加明确。

Any developer working on a complex system can write good code and maintain it for a short while. However, without synergy between the source code and the problem domain, continued development will likely end up in a codebase that is hard to modify, resulting in a BBoM. DDD helps with this issue by placing emphasis on the team to continually look at how useful the model is for the current problem. It challenges the team to evolve and simplify complex models of domains as and when it gains domain insights. DDD is still no silver bullet and requires dedication and constant knowledge crunching to produce software that is maintainable for years and not just months. New business cases may break a previously useful model, or may necessitate changes to make new or existing concepts more explicit.

战术模式是 DDD 的关键

Tactical Patterns Are Key to DDD

DDD 并非一本关于面向对象设计的书，也不是以代码为中心的哲学或模式语言。然而，如果你在网上搜索 DDD 的文章，你可能会误以为它只是一些实现模式，因为大多数关于 DDD 的文章和博客都侧重于建模模式。对于开发人员来说，更容易看到 DDD 战术模式在代码中的实现，而不是业务用户和团队之间的对话。他们不关心或不理解的领域。这就是为什么 DDD 有时会被误认为仅仅是由实体、值对象和存储库组成的模式语言。事实上，你无需创建丰富的领域模型或使用存储库即可实现 DDD。DDD 与其说是软件设计模式，不如说是通过协作解决问题。

DDD is not a book on object-oriented design, nor is it a code-centric philosophy or a patterns language. However, if you search the web for articles on DDD, you would be mistaken for thinking that it is just a handful of implementation patterns as most articles and blogs on DDD focus on the modeling patterns. It is much easier for developers to see tactical patterns of DDD implemented in code rather than conversations between business users and teams on a domain that they do not care about or do not understand. This is why DDD is sometimes mistakenly thought of as nothing more than a pattern language made up of entities, value objects, and repositories. You can, in fact, implement DDD without ever creating a rich domain model or using a repository. DDD is less about software design patterns and more about problem solving through collaboration.

Evans 介绍了一些使用软件设计模式的技术，使开发团队和业务专家创建的模型能够通过 UL 实现。然而，如果没有分析和协作的实践，编码实现本身就毫无意义。DDD 并非以代码为中心；它的目的并非编写优雅的代码。软件仅仅是 DDD 的产物。

Evans presents techniques to use software design patterns to enable models created by the development team and business experts to be implemented using the UL. However, without the practices of analysis, and collaboration, the coding implementation really means very little on its own. DDD is not code centric; its purpose is not to make elegant code. Software is merely an artifact of DDD.

DDD 是一个框架

DDD Is a Framework

DDD 不需要特殊的框架或数据库。代码中实现的模型遵循 POCO（Plain Old C# Object，简单老式 C# 对象）原则，确保其不包含任何基础结构代码，从而不会影响其以领域为中心的目的。面向对象方法对于构建模型很有用，但绝非强制性要求。

DDD does not require a special framework or database. The model implemented in code follows a POCO (Plain Old C# Object) principle that ensures it is devoid of any infrastructural code so that nothing distracts from its domain-centric purpose. An object-oriented methodology is useful for constructing models, but it is by no means mandatory.

DDD 与架构无关，这意味着实现 DDD 时无需遵循单一的架构风格。Evans 的著作中提出了一种分层架构风格，但这并非唯一选择。架构风格可以多种多样，因为它们应该应用于有界上下文级别，而不是应用程序级别。一个产品可以包含一个遵循以事件为中心的架构的有界上下文，另一个采用分层富领域模型的有界上下文，以及第三个应用活动记录模式的有界上下文。

DDD is architecturally agnostic in that there is no single architectural style you must follow to implement it. A layered architectural style was presented in Evans’s text, but this is not the only option. Architectural styles can vary because they should apply at the bounded context level and not the application level. A single product can include one bounded context that follows an event-centric architecture, another that utilizes a layered rich domain model, and a third that applies the active record pattern.

DDD 是银弹

DDD Is a Silver Bullet

DDD 可能需要投入大量精力，它需要迭代式的开发方法、积极的业务投入以及优秀的开发人员。所有软件项目都可以受益于 DDD 的分析实践（例如提炼问题域）以及战略模式（例如隔离代表领域逻辑的代码模型）。然而，并非所有项目都需要 DDD 的战术模式来构建丰富的领域模型。一些简单的领域模型由于缺乏或完全没有领域逻辑，因此无法达到如此复杂的程度。例如，在创建一个简单的博客应用程序时，应用所有 DDD 模式将浪费时间和成本。

DDD can take a lot of effort, it requires an iterative development methodology, an engaged business, and smart developers. All software projects can benefit from the analysis practices of DDD such as distilling the problem domain as well as the strategic patterns such as isolating a code model that represents domain logic. However, not all require the tactical patterns of DDD to build a rich domain model. Trivial domains don’t warrant the level of sophistication as they have little or no domain logic. For example, it would be a waste of time and costly to apply all of the patterns of DDD when creating a simple blogging application.

通过共同语言达成共同理解

Reaching a Shared Understanding through a Shared Language

知识梳理的成果和共享理解的产物是一种通用的通用语言 (UL)。在与利益相关者和领域专家进行建模时，每个人都应有意识地始终如一地应用一种富含领域特定术语的通用语言。这种语言必须明确，并在描述领域模型和问题领域时使用。该语言也应应用于模型的代码实现，并使用与类名、属性和方法名相同的术语和概念。这种语言使业务团队和开发团队能够就软件进行有意义的沟通。您将在第 4 章“模型驱动设计”中了解有关 UL 的更多信息。

An output of knowledge crunching and an artifact of the shared understanding is a common Ubiquitous Language (UL). When modeling with stakeholders and subject matter experts everyone should make a conscious effort to consistently apply a shared language rich in domain-specific terminology. This language must be made explicit and be used when describing the domain model and problem domain. The language should also be used in the code implementation of the model, with the same terms and concepts used as class names, properties, and method names. It is the language that enables both the business and development teams to have meaningful communication about the software. You will learn more about the UL in Chapter 4, “Model-Driven Design.”

UL 用于将模型的代码表示与以业务人员能够理解的语言和图表形式传达的概念模型绑定在一起。UL 将包含业务术语以及在对问题域用例进行建模时发现的新概念和术语。UL 的共同理解避免了不断地从技术模型转换为业务模型，从而消除了重要洞察的丢失风险。

UL is used to bind the code representation of the model to the conceptual model communicated in language and diagrams, which the business can understand. The UL will contain terminology from the business as well as new concepts and terms discovered when modeling the use case of the problem domain. The shared understanding that a UL prevents the need to constantly translate from a technical model to a business model, thus removing the chance of vital insight being lost.

领域知识的重要性

The Importance of Domain Knowledge

领域知识至关重要，甚至比技术诀窍更为关键。在流程和逻辑复杂的业务中工作的团队需要深入问题领域，像海绵一样吸收所有相关的领域知识。这种洞察力将使团队能够专注于关键点，并在应用程序代码库的核心创建一个能够满足业务用例并在应用程序的整个生命周期内持续发挥作用的模型。

Domain knowledge is key, even more so than technical know-how. Teams working in a business with complex processes and logic need to immerse themselves in the problem domain and, like a sponge, absorb all the relevant domain knowledge. This insight will enable teams to focus on the salient points and create a model at the heart of their application’s code base that can fulfill the business use cases and keep doing so over the lifetime of the application.

如果您无法用简单的语言与业务用户解释问题域中的复杂概念，那么您还没有准备好开始在该领域开发软件。为了能够持续快速地更新您正在构建的复杂应用程序，即使业务不断变化，功能也需要不断更新，您需要在设计和开发过程中重新调整工作重点——您需要让您的团队专注于业务问题，而不仅仅是技术。

If you can’t speak to your business users in simple terms about complex concepts in the problem domain, you are not ready to start developing software within it. To constantly deliver updates at a rapid pace on the complex applications you are building, even as the whimsical business keeps chopping and changing features, you need to refocus your efforts during design and development—you need to focus your team on the business’s problems and not just technologies.

业务分析师的作用

The Role of Business Analysts

在 DDD 的世界里，传统业务分析师的角色似乎已不复存在；然而，事实并非如此。业务分析师仍然可以帮助利益相关者充实他们的初步想法，并捕捉产品的输入和输出。如果您手下有一些奇葩的开发人员，并且不敢让他们与领域专家面对面交流，您也可以聘请业务分析师作为沟通的引导者。您肯定不希望切断开发团队与最了解该业务领域的人员之间的直接沟通。

It may seem that the role of the traditional business analyst is no longer required in the world of DDD; however, this is not the case. A business analyst can still help stakeholders flesh out their initial ideas and capture inputs and outputs of the product. If you have odd whiz-kid developers and are nervous about putting them in front of domain experts, you can also use business analysts as facilitators to help communication. What you don’t want to do is remove the direct communication between the development team and the people who understand that part of the business the most.

持续进行的过程

An Ongoing Process

知识挖掘是一个持续的过程；团队应该持续努力，以简化问题领域的视角，只关注相关部分，以帮助创建有用的模型。正如您将在第4章中了解到的，模型驱动设计和领域模型的演进是一个持续的过程。为了确保您拥有一个适用于系统当前用例的有用模型，必须舍弃许多模型。开发团队、业务利益相关者和主题专家之间的协作不应局限于项目初期。知识挖掘应该成为业务部门在应用程序构建的整个生命周期中持续关注的问题。

Knowledge crunching is an ongoing process; teams should continually be working toward a simple view of the problem domain that focuses only on the relevant pieces to aid the creation of a useful model. As you will learn in Chapter 4, model-driven design and the evolution of a domain model is an ongoing process. Many models must be rejected in order to ensure you have a useful model for the current use cases of a system. Collaboration between the development team, business stakeholders, and subject matter experts should not be constrained to the start of a project. Knowledge crunching should be an ongoing concern with the business engaged throughout the lifetime of the application build.

重要的是要意识到，随着系统的每次迭代，模型都会不断发展。它会随着新需求的增加而变化。新的行为和用例将需要对模型进行修改，因此技术团队和业务专家必须明白，模型永远不会完成；它只对当前的问题有用。

It is important to realize also that with each iteration of the system the model will evolve. It will change as and when new requirements are added. New behaviors and use cases will require changes to the model therefore it is important for the technical team and the business experts to understand that the model is never done; it is only useful for the problems at hand.

随着每次迭代的推进，团队对问题领域的理解不断加深。这将带来更深入的洞察和设计突破，从而极大地简化模型。在系统投入使用时，模型可能还需要由于技术原因（例如性能或更好地理解系统使用情况）而进行改进。一个好的模型应该能够灵活地应对变化；一个成熟的模型应该包含丰富且富有表现力的问题领域概念和术语，并且能够被业务团队和技术团队理解。

As each iteration passes the team’s understanding of the problem domain improves. This leads to deeper insight and design breakthroughs that can vastly simplify a model. When the system is in use the model may also need to evolve due to technical reasons such as performance or better understanding of the systems usage. A good model is one that is supple to change; a mature model holds rich and expressive concepts and terminology of the problem domain and is understood by both the business and technical teams.

领域专家 vs 利益相关者

Domain Experts vs Stakeholders

问题空间为您提供一组需求、输入和预期输出——这些通常由您的利益相关者提供。解决方案空间包含一个能够满足需求的模型——这正是领域专家可以提供帮助的地方。

A problem space gives you a set of requirements, inputs, and expected outputs—this is usually provided from your stakeholders. A solution space contains a model that can meet the needs of the requirements—this is where domain experts can help.

如图 2.2所示，如果您的利益相关者不是领域专家，那么他的角色将与领域专家的角色大不相同。利益相关者会告诉您他们希望系统做什么；他们会关注输入和输出。而领域专家则会与您合作，以生成一个有用的模型，该模型既能满足利益相关者的需求，又能满足应用程序的行为。

As shown in Figure 2.2 if your stakeholder is not a domain expert then his role will differ greatly from that of a domain expert. A stakeholder will tell you what they want the system to do; they will focus on the inputs and outputs. A domain expert on the other hand will work with you in order to produce a useful model that can satisfy the needs of a stakeholder and the behaviors of the application.

更深入地了解业务

Deeper Understanding for the Business

与领域专家合作，不仅能让开发团队了解他们正在处理的问题领域，还能帮助领域专家完善自己对该领域的理解。业务部门可能隐性理解的概念，现在由开发团队和领域专家明确定义，从而改善业务部门内部的沟通。

Working with a domain expert will not only enable development teams to gain knowledge about the problem domain that they are working in but also help the domain expert to qualify her understanding of the domain. Concepts that may have been implicitly understood by the business are explicitly defined by the development team and domain expert, which leads to improved communication within the business itself.

与你的领域专家合作

Engaging with Your Domain Experts

为了实现高水平的协作，建议为开发团队安排领域专家，让他们能够在走廊或休息室的临时会议上解答问题并参与分析；如果沟通仅限于每周的项目会议，就会失去这些。协作是领域驱动设计 (DDD) 的重要组成部分；没有协作，许多设计突破就无法实现。正是这种更深入的设计洞察，使软件能够有效运作，并适应业务流程的变化。

To enable a high level of collaboration, it is recommended that you collocate the development team with domain experts who will be on hand to answer questions and participate during analysis at impromptu corridor or break room meetings; that’s something that is lost when the communication is restricted to weekly project meetings. Collaboration is such an essential part of DDD; without it, a lot of the design breakthroughs would not happen. It is this deeper design insight that makes the software useful and able to adapt when the business processes change.

如果无法与你的领域专家坐在一起，那就和她一起吃午饭。尽可能多地和她在一起，尽可能多地学习。如果你致力于交付高质量的软件来满足个人需求或实现职业目标，那么就把吃饭、睡觉、呼吸都投入到这个领域——你将获得巨大的回报。

If it’s not possible to sit with your domain expert, join her for lunch. Spend as much time as you can with her, and learn as much as possible. If you thrive on delivering high-quality software for personal satisfaction or career goals, then eat, sleep, and breathe the domain—you will be immensely rewarded

关注最有趣的对话

Focus on the Most Interesting Conversations

不要让领域专家和业务利益相关者逐一过一遍需求清单，让他们感到厌烦。如前所述，领域专家的时间非常宝贵。从那些让业务部门夜不能寐的问题领域开始，这些领域将对……产生重大影响。业务的关键在于哪些因素是应用程序成功的关键。例如，询问领域专家当前系统中哪些部分难以使用，哪些手动流程阻碍了他们开展更具创造性、增值性的工作。或者，哪些变革可以增加收入、提高运营效率并节省成本。追踪资金流向，寻找哪些领域正在浪费业务成本或阻碍收入增长，通常是一个好主意。最有趣的对话将揭示您应该在哪些方面投入更多精力来建立共识和共同语言。

Don’t bore domain experts and business stakeholders by going through a list of requirements with them one item at a time. As stated before, a domain expert’s time is precious. Start with the areas of the problem domain that keep the business up at night—the areas that will make a difference to the business and that are core for the application to be a success. For example, asking the domain experts which parts of the current system are hard to use, or which manual processes stop them from doing more creative, value-adding work. Or what changes would increase revenue or improve operational efficiencies and save money from the bottom line. It’s often a good idea to follow the money and look for the areas that are costing the business money or preventing them from increasing revenue. The most interesting conversations will reveal where you should spend most of your effort on creating a shared understanding and a shared language.

从用例开始

Start from the Use Cases

尝试理解新领域时，最好的起点是绘制用例图。用例列出了实现目标所需的步骤，包括用户与系统之间的交互。与业务用户合作，了解用户如何使用当前系统，无论是纸质流程还是计算机化流程。仔细聆听领域术语，因为这构成了描述和沟通问题领域的通用语言的开端。用你自己的理解向领域专家复述用例图也很有用，这样他们就能验证你是否和他们一样理解了用例。记住：绘制现实的流程图，理解工作流程的本来面目，在真正理解和把握问题之前，不要急于跳到解决方案。

The best place to start when trying to understand a new domain is by mapping out use cases. A use case lists the steps required to achieve a goal, including the interactions between users and systems. Work with business users to understand what users do with the current system, be it a paper-based process or one that’s computerized. Be careful to listen for domain terminology, because this forms the start of your shared language for describing and communicating the problem domain. It’s also useful to read back the use case to the domain expert in your own understanding, so they can validate that you do understand the use case as they do. Remember: capture a process map of reality, understand the work flow as it is, and don’t try to jump to a solution too quickly before you truly understand and appreciate the problem.

提出有力的问题

Ask Powerful Questions

好的产品是什么样的？这款产品的成功标准是什么？什么让它值得投入？企业想要实现什么目标？在知识问答环节中提出的问题将极大地帮助你理解正在开发的产品的重要性及其背后的意图。

What does good look like? What is the success criteria of this product? What will make it a worthwhile endeavor? What is the business trying to achieve? The questions you ask during knowledge-crunching sessions will go a long way toward your understanding of the importance of the product you are building and the intent behind it.

以下是一些示例，可以让您的领域专家进行讨论并揭示对该领域的更深入的见解：

Here are some examples to get your domain expert talking and revealing some deeper insight into the domain:

• 这个系统的需求从何而来？
• Where does the need of this system come from?
• 这个系统将如何为企业创造价值？
• How will this system give value to the business?
• 如果没有建立这个系统会发生什么？
• What would happen if this system wasn’t built?

草图绘制

Sketching

人们通常通过观察所讨论概念的视觉表达来更快地学习。绘制简单的图表是领域驱动设计 (DDD) 从业者常用的一种可视化技巧，可以增强知识的消化，并最大限度地利用与领域专家交流的时间。

People often learn quicker by seeing visual representations of the concepts they are discussing. Sketching simple diagrams is a common visualization technique DDD practitioners use to enhance knowledge-crunching sessions and maximize their time with domain experts.

你可以先在白板或纸上画草图。只要保持快速和非正式的表达，就能随着讨论的进展快速迭代。

You can start by drawing sketches on the whiteboard or on paper. If you keep them quick and informal you can quickly iterate on them as the conversation progresses.

遗憾的是，许多开发人员发现创建有效的图表非常困难。然而，在绘制草图时，一个基本原则可以帮助您创建高效的图表：保持图表的细节层次一致。如果您讨论的是高级概念，例如独立软件系统如何通信以实现业务用例，请尽量避免深入到类或模块名称等会使图表变得混乱的低级概念。保持图表的细节层次一致可以避免显示过多或过少的细节，从而确保每个人都能理解您想要表达的内容。通常，最好创建多个不同细节层次的图表。

Unfortunately, many developers find it difficult to create effective diagrams. However, when drawing sketches, one basic principle can help you to create highly effective diagrams: keep your diagrams at a consistent level of detail. If you’re talking about high-level concepts like the way independent software systems communicate to fulfill a business use case, try not to drop down into lower-level concepts like class or module names that will clutter the diagram. Keeping your diagrams at a consistent level of detail will prevent you from showing too much detail or too little detail, meaning everyone can understand what you are trying to convey. It’s often better to create multiple diagrams each at a different level of detail.

UML 是一种非常棒的语言，即使你缺乏技术专业知识，也能用它以通俗易懂的方式交流复杂的系统。然而，对于快速的知识梳理会议来说，它可能过于正式，因为团队需要反复尝试和建模。不要尝试使用 Visio 或 Rational Rose 等复杂的软件来捕捉动态模型。相反，你应该在白板上画出模型草图。相比于用 Visio 画出一个耗时半天的图表，你更不会对花几分钟时间画的草图感到执着。如果你必须记录你的知识梳理会议，请在你对问题领域了解最多的时候再写。

UML is a wonderful language you can use to communicate complex systems in an understandable manner with little or no technical expertise. However it maybe too formal for rapid knowledge-crunching sessions, as the team will need to retry and model many times. Don’t try to use elaborate packages such as Visio or Rational Rose to capture a moving model. Instead, sketch out the model on the whiteboard. You will be less attached to a sketch that took you minutes to draw than a diagram in Visio that took you most of the morning. If you must write up your knowledge-crunching sessions, do it at the end when you know the most about the problem domain.

班级职责协作卡

Class Responsibility Collaboration Cards

以可视化的方式捕捉信息是快速传达想法和概念的有效方法。然而，由于 DDD 是围绕共享语言的核心思想构建的，因此使用专注于创建简洁而强大的语言的知识收集技术至关重要。

Capturing information visually is an effective way to quickly communicate ideas and concepts. However, because DDD is built around the core idea of a shared language, it is important to use knowledge-gathering techniques that focus on creating a concise and powerful language.

CRC（类职责协作）卡片分为三个区域，包含以下信息：

CRC (Class Responsibility Collaboration) cards are divided into three areas and contain the following information:

• 类名，代表领域中的概念
• A class name, which represents a concept in the domain
• 班级职责
• The responsibilities of the class
• 与实现其目的相关的、必需的类
• Classes that are associated and are required to fulfill its purpose

CRC 卡让团队和业务专家集中思考问题领域中概念的语言。

CRC cards focus the team and the business experts on thinking about the language of the concepts in the problem domain.

推迟模型中概念的命名

Defer the Naming of Concepts in Your Model

在对领域进行建模时，命名非常重要。但是，当您通过进一步的知识梳理发现概念与您最初的理解不同时，过早命名可能会带来问题。问题在于与最初选定的名称的关联，以及它如何影响您的思维。Greg Young 建议（http://codebetter.com/gregyoung/2012/02/28/the-gibberish-game-4/）使用胡言乱语来表示您不确定的模型区域。我倾向于使用颜色，但想法是一样的。不要给模型的区域或概念赋予真实名称，而是使用胡言乱语，直到您理解了关注点的所有职责、行为和数据。推迟对模型中的概念进行命名将大大有助于您避免对您正在试图改变的现实进行建模以使业务受益。

Naming is important when modeling a domain. However, premature naming can be a problem when you discover through further knowledge crunching that concepts turn out to be different from what you first understood them to be. The issue is the association with the word that was chosen as the original name and the way it shapes your thinking. Greg Young suggests (http://codebetter.com/gregyoung/2012/02/28/the-gibberish-game-4/) making up words for areas of the model you are not sure about, using gibberish. I tend to favor using colors, but the idea is the same. Instead of giving areas or concepts of the model real names, use gibberish until you have understood all the responsibilities, behavior, and data of a concern. Deferring the naming of concepts in your model will go a long way toward helping you avoid modeling a reality that you are trying to change to the business’s benefit.

还要注意术语重载。要避免使用 XXXXService 和 XXXXManager 等类型的名称。如果您发现自己在类或概念后附加了服务或管理器，请更具创造性地思考，努力理解名称背后的真正含义。当您觉得自己真正理解了模型的某个部分时，就能更好地为其赋予一个合理且有意义的名称。

Also look out for overloaded terms. The types of names that you want to avoid are XXXXService and XXXXManager. If you find yourself appending service or manager to a class or concept, think more creatively, strive for real intent behind a name. When you feel you have really understood a part of the model, you will be in a better place to give it a sensible and meaningful name.

行为驱动开发

Behavior-Driven Development

行为驱动开发 (BDD) 是一种基于测试驱动开发 (TDD) 的软件开发过程，它专注于捕捉系统的行为，然后从外部推动设计。BDD 在与领域专家和利益相关者的对话中使用具体的领域场景来描述系统的行为。

Behavior-Driven Development (BDD) is a software development process, based on Test-Driven Development (TDD), which focuses on capturing the behavior of a system and then driving design from the outside in. BDD uses concrete domain scenarios during conversations with domain experts and stakeholders to describe the behaviors of a system.

与 DDD 类似，BDD 并不关注应用程序的技术层面。两者的区别在于，BDD 关注的是软件行为，即系统应该如何运行；而 DDD 则关注的是软件核心的领域模型，用于实现这些行为——这是一个细微但重要的区别。

Much like DDD, BDD does not focus on the technical aspects of an application. Where it differs is that BDD focuses on the software behavior, how the system should behave, whereas DDD focuses on the domain model at the heart of the software that is used to fulfil the behaviors—a small but important distinction.

BDD 有其自己的 UL 形式来指定需求——一种分析语言，或者说，GWT（Given, When, Then）。GWT 格式有助于构建与领域专家的对话，并揭示领域的实际行为。

BDD has its own form of UL to specify requirements—an analysis language, if you will, known as GWT (Given, When, Then). The GWT format helps to structure conversations with domain experts and reveal the real behaviors of a domain.

为了演示如何使用 BDD，请查看如何利用用户故事捕获产品需求。

To demonstrate how BDD is used, look at how the requirements for a product are captured utilizing user stories.

电子商务网站功能示例：

An example of a feature for an e-commerce site:

特色：大额订单免费送货

Feature: Free Delivery for Large Orders

此功能的一些故事可能是：

Some stories for this feature may be:

为了提高平均订单总额（50 美元），

In order to increase the average order total, which is $50,

作为营销经理

As the marketing manager

如果顾客消费 60 美元，我愿意提供免费送货服务。

I would like to offer free delivery if customers spend $60.

此功能的另一个故事示例：

Another story example for this feature:

为了针对具有不同消费习惯的不同国家，

In order to target different countries that have different spending habits,

作为营销经理

As the marketing manager

我想为每个配送国家/地区设置合格订单总数门槛。

I would like to set the qualifying order total threshold for each delivery country.

功能描述的是能够为业务带来价值的行为。功能故事中还会包含角色和优势。清晰地描述与功能相关的角色，能够帮助开发团队以及领域专家了解应该与谁沟通或由谁代理。优势能够证明该功能存在的合理性，有助于阐明业务用户为何需要该功能。

A feature describes a behavior that gives value to the business. In a feature story, a role and benefit are also included. The clarity of the role that relates to the feature enables the development team, along with domain experts, to understand who to talk to or who to proxy. The benefit justifies the existence of the feature, helping to clarify why the business user wants the feature.

为了更好地理解某个功能及其行为，可以使用 BDD 场景来描述该功能在不同用例下的行为。场景始于一个初始条件（Givens）。然后，场景包含一个或多个事件（Whens），最后描述预期结果（Thens）。

To better understand a feature and its behavior, use BDD scenarios to describe the feature under different use cases. Scenarios start with an initial condition, the Givens. Scenarios then contain one or more events, the Whens, and then describe the expected outcomes, the Thens.

BDD 场景示例：

An example of a BDD scenario:

场景：客户满足免费送货的消费门槛

Scenario: Customer satisfies the spend threshold for free delivery

假设：免费送货的门槛设定为 60 美元

Given: Threshold for free delivery is set at $60

并且：我是一名顾客，购物篮总额为 50 美元

And: I am a customer who has a basket totaling $50

时间：我将一件价值 11 美元的商品添加到购物车

When: I add an item to my basket costing $11

然后：我应该享受免费送货服务

Then: I should be offered free delivery

进一步的例子：

A further example:

场景：客户未达到免费送货的消费门槛，但触发了追加销售消息

Scenario: Customer does not satisfy the spend threshold for free delivery but triggers message to up sale

假设：免费送货的门槛设定为 60 美元

Given: Threshold for free delivery is set at $60

并且：我是一名顾客，购物篮总额为 50 美元

And: I am a customer who has a basket totaling $50

时间：我将一件价值 9 美元的商品添加到购物车

When: I add an item to my basket costing $9

然后：我应该被告知，如果我的购物篮商品总额增加 1.00 美元，我将享受免费送货服务

Then: I should be told that if I increase my basket goods total by $1.00, I will be offered free delivery

除了作为捕获需求的轻松方式之外，场景还提供了验收标准，开发人员和测试人员可以使用它来确定功能何时完成，业务用户可以使用它来确认团队是否理解该功能。

In addition to being a light way of capturing requirements, the scenarios provide acceptance criteria that developers and testers can use to determine when a feature is complete, and business users can use to confirm that the team understands the feature.

使用这种捕获需求的方法可以消除传统需求文档可能造成的歧义，同时还能显著强调领域语言。功能和场景是开发团队和业务专家协作的成果，有助于塑造最终用户定义框架 (UL)。

Using this method of capturing requirements removes the ambiguity that traditional requirement documentation can result in while also heavily emphasizing the domain language. The features and scenarios are a product of collaboration between the development team and business experts, and can help to shape the UL.

快速成型

Rapid Prototyping

在知识研讨环节，优先考虑快速原型设计。业务用户最喜欢屏幕模型，因为它们能更深入地揭示产品背后的意图。用户理解用户界面；他们可以与之交互，并清晰地执行工作流程。

Favor rapid prototyping during knowledge-crunching sessions. Business users like nothing more than screen mock-ups, because they reveal so much more about the intent they have behind a product. Users understand UI; they can interact with it and act out work flows clearly.

快速原型设计的另一种形式是用代码捕获需求。Greg Young 将这种代码称为分析；他有一个关于此主题的演示文稿，我们可以在这里访问：http://skillsmatter.com/podcast/open-source-dot-net/mystery-ddd。同样，业务用户会喜欢你在他们眼前编写和创作。开始编写代码有助于集中精力进行分析。开始将知识梳理中的抽象想法付诸实践，将使你能够验证和证明你的模型。这也有助于避免只停留在抽象思维，因为抽象思维可能会导致分析瘫痪（http://sourcemaking.com/antipatterns/analysis-paralysis）。

Another form of rapid prototyping is to capture requirements in code. Greg Young calls this code as analysis; he has a presentation on this topic we can access here: http://skillsmatter.com/podcast/open-source-dot-net/mystery-ddd. Again, business users will love the fact that you are writing and creating before their eyes. Starting to code will help focus analysis sessions. Starting to implement abstract ideas from knowledge crunching will enable you to validate and prove your model. It also helps to avoid only abstract thinking, which can lead to analysis paralysis (http://sourcemaking.com/antipatterns/analysis-paralysis).

快速编码有助于创建有力的问题，并有助于找到缺失的用例。使用代码来识别和解决问题。经过大约一个小时的讨论后，看看能否为你的头脑风暴创建一个代码模型。我经常发现，用代码实现想法有助于巩固领域概念并验证模型设计。这个过程有助于保持开发团队的参与度，并让他们全神贯注于学习领域知识，因为他们可以立即获得关于设计的反馈。

Coding quickly helps create your powerful questions and helps find missing use cases. Use the code to identify and solve the problems. After an hour or so of talking, see if you can create a code model of your brainstorming. I often find that implementing ideas in code helps to cement domain concepts and prove model designs. This process helps to keep the development team engaged and deeply engrossed in learning about the domain as they can start to get feedback on a design immediately.

记住：只创建与特定问题相关的代码模型，并使其符合特定的上下文环境；你无法有效地对整个领域进行建模。从小处着眼，围绕规则进行建模；然后逐步构建。最重要的是，记住你编写的是一次性代码。不要止步于第一个有用的模型，也不要过于执着于你的第一个好主意。

Remember: Only create a code model of what is relevant and within the specific context to solve a given problem; you can’t effectively model the entire domain. Think small and model around rules; then build up. Most important, remember that you are writing throw-away code. Don’t stop at the first useful model, and don’t get too attached to your first good idea.

看看纸质系统

Look at Paper-Based Systems

如果您正在为一个尚未有软件解决方案的问题领域开发解决方案，请关注企业在当前纸质解决方案中如何使用语言。某些流程和工作流程可能无法从处理边缘情况的复杂模型中获益。对于罕见的边缘情况，将权力交还给手动流程或许能更好地解决；建模可能会耗费大量精力，却收效甚微。

If you are developing a solution for a problem domain that does not have an existing software solution, look to how the business uses language in the current paper-based solution. Some processes and work flows may not benefit from an elaborate model to handle edge cases. Rare edge-case scenarios may be better solved by handing power back to the manual process; modeling this may result in a lot of effort for little business value.

理解意图

Understanding Intent

警惕客户对现有软件的增强要求，因为他们通常会根据现有系统的局限性而不是他们真正的需求提出要求。问问自己，你有多少次与用户沟通，真正了解了需求背后的动机。你是否理解了需求背后的原因？一旦你分享并理解了客户的真正需求，你通常就能提出更好的解决方案。当你像这样与客户沟通，然后紧接着一句经典台词：“哦，真的吗？我不知道。”“你能做到！”记住：你是赋能者。不要盲目遵循用户的需求。业务用户可能无法编写有效的功能或有效地表达目标。你必须分享并理解底层愿景，并了解业务部门想要实现的目标，这样你才能创造真正的商业价值。

Be wary of customers asking for enhancements to existing software, because they will often give you requirements that are based on the constraints of the current systems rather than what they really desire. Ask yourself how often you have engaged with a user to really find the motivation behind a requirement. Have you understood the why behind the what? Once you share and understand the real needs of a customer, you can often present a better solution. Customers are usually surprised when you engage them like this, quickly followed by the classic line: “Oh, really? I didn’t know you could do that!” Remember: You are the enabler. Don’t blindly follow the user’s requirements. Business users may not be able to write effective features or effectively express goals. You must share and understand the underlying vision and be aware of what the business is trying to achieve so you can create real business value.

事件风暴

Event Storming

事件风暴是一项研讨会活动，旨在以有趣且引人入胜的方式，帮助业务团队和开发团队快速理解问题领域。领域专家（拥有答案的人）和开发团队成员（拥有疑问的人）共同协作，对问题领域达成共识。知识碰撞发生在一个开放的环境中，该环境拥有充足的空间用于可视化建模，无论是大量的白板还是无尽的牛皮纸卷。

Event Storming is a workshop activity that is designed to quickly build an understanding of a problem domain in a fun and engaging way for the business and development teams. Groups of domain experts, the ones with the answers, and development team members, the ones with the questions, work together to build a shared understanding of the problem domain. Knowledge crunching occurs in an open environment that has plenty of space for visual modeling, be that lots of whiteboards or an endless roll of brown paper.

问题域的探索始于领域事件；即发生在问题域中且业务关注的事件。将代表领域事件的便利贴添加到绘图表面，然后关注该事件的触发因素。事件可能由用户操作引发，该操作被捕获并作为命令添加到绘图表面。外部系统或其他事件可能是事件的发起者；这些也会被添加到画布中。此活动持续到没有其他问题为止。然后，团队可以开始围绕事件的决策点以及它们何时产生新事件来构建模型。

The problem domain is explored by starting with a domain event; i.e., events that occur within the problem domain that the business cares about. A Post-it note representing the domain event is added to the drawing surface and then attention is given to the trigger of that event. An event could be caused by a user action that is captured and added to the surface as a command. An external system or another event could be the originator of the event; these are also added to the canvas. This activity continues until there are no more questions. The team can then start to build a model around the decision points that are made about events and when they, in turn, produce new events.

事件风暴对于培养 UL 来说是一项极其有用的活动，因为每个事件和命令都有明确的名称，这有助于在开发人员和业务专家之间达成共识。它还可以揭示问题域的子域和核心域，这将在第 3 章“关注核心域”中详细介绍。然而，它最大的好处在于它有趣、引人入胜，而且可以快速完成。这项活动由 Alberto Brandolini 创建，更多信息请访问他的博客http://ziobrando.blogspot.co.uk/。

Event storming is an extremely useful activity for cultivating a UL as each event and command is explicitly named, this goes a long way to producing a shared understating between the developers and business experts. It can also reveal sub domains and the core domain of the problem domain, which will be covered in detail in Chapter 3, “Focusing on the Core Domain.” The biggest benefit however is that it’s fun, engaging, and can be done quickly. Alberto Brandolini created this activity and more information can be found on his blog at http://ziobrando.blogspot.co.uk/.

影响图

Impact Mapping

一种能够更好地理解业务利益相关者意图的新技术是影响图。通过影响图，您可以超越传统的需求文档，尝试了解企业试图产生的影响。他们想要增加销售额吗？他们的目标是扩大市场份额吗？他们想进入一个新市场吗？也许他们想提高参与度，以创造更多具有更高终身价值的忠诚客户。

A new technique for better understanding the intent of business stakeholders is impact mapping. With impact mapping, you go beyond a traditional requirements document and instead you try to work out what impacts the business is trying to make. Do they want to increase sales? Is their goal to increase market share? Do they want to enter a new market? Maybe they want to increase engagement to create more loyal customers who have a higher lifetime value.

一旦你了解了业务部门想要产生的影响，你就能更有效地帮助他们实现目标。对于领域驱动设计 (DDD) 来说，重要的是，由于你了解业务部门想要实现的目标，你将能够在知识交流环节提出更好的问题。

Once you understand the impact the business is trying to make you can play a more effective role in helping them to achieve it. Significantly for DDD, you will be able to ask better questions during knowledge-crunching sessions since you know what the business wants to achieve.

令人惊讶的是，影响力图谱绘制其实是一种非常非正式的技术。你只需创建类似思维导图的图表，突出关键的业务信息即可。你与业务部门合作，就像知识整合一样，这是一种协作活动，有助于构建产品的共同愿景。图 2.3展示了一个影响力图示例，展示了一家电商公司希望实现的提升 25% 自行车销量的目标。

Surprisingly, impact mapping is a very informal technique. You simply create mind-map-like diagrams that accentuate key business information. You work with the business so that, like knowledge crunching, it is a collaborative exercise that helps to build up a shared vision for the product. Figure 2.3 shows an example impact map demonstrating an e-commerce company’s desired impact of selling 25% more bicycles.

很明显，影响图从影响开始。在图 2.3中，正如所提到的，这就是多销售 25% 的自行车。与影响直接相关的是参与者——那些可以为实现预期影响做出贡献的人。在图 2.3中，这些参与者是开发人员和数据科学家。参与者的子节点是参与者可以提供帮助的方式。在图 2.3中，开发人员可以帮助创造业务影响的一种方法是提高网站的性能，以便人们更有可能进行购买。最后，层次结构的最后一级显示了可以执行的实际任务。您可以在图 2.3中看到，开发人员可以加快网站速度的一种方法是删除速度慢的框架。

An impact map, rather obviously, starts with the impact. In Figure 2.3, this is to sell 25% more bicycles, as mentioned. Directly connected to the impact are the actors—the people who can contribute to making the desired impact. In Figure 2.3, that would be developers and data scientists. Child nodes of the actors are the ways in which the actors can help. In Figure 2.3, one way the developers can help to create the business impact is to improve the performance of the website so that people are more likely to make a purchase. Finally, the last level of the hierarchy shows the actual tasks that can be carried out. You can see in Figure 2.3 that one way the developers may be able to make the website faster is to remove slow frameworks.

在许多软件项目中，开发人员只能获得影响图的底层——业务部门认为他们需要什么，以及他们认为开发人员应该如何实现这些目标。然而，通过影响图，你可以解开他们的假设，找出他们真正想要实现的目标。然后您可以利用您的技术专长来提出他们从未想到过的更好的替代方案。

On many software projects the developers only get the lower tiers of an impact map—what the business thinks they need and how they think the developers should achieve it. With an impact map, though, you can unwind their assumptions and find out what they really want to achieve. And then you can use your technical expertise to suggest superior alternatives that they would never have thought of.

一些 DDD 从业者对影响图的评价很高，无论将其与 DDD 结合使用还是单独使用。我们强烈建议您浏览网站 ( http://www.impactmapping.org/ ) 或阅读 Gojko Adzic 所著的《影响图》一书，深入了解影响图。

Some DDD practitioners rate impact mapping very highly, both when applied with DDD or in isolation. You are highly encouraged to investigate impact mapping by browsing the website (http://www.impactmapping.org/) or picking up a copy of the book: “Impact Mapping,” by Gojko Adzic.

了解商业模式

Understanding the Business Model

商业模式包含大量有用的领域信息，并强调了企业的基本目标。遗憾的是，很少有开发人员花时间去了解雇主的商业模式，甚至去理解商业模式的真正含义。

A business model contains lots of useful domain information and accentuates the fundamental goals of a business. Unfortunately, very few developers take the time to understand the business model of their employers or even to understand what business models really are.

了解一家公司商业模式的最佳方法之一是使用商业模式画布将其可视化；亚历山大·奥斯特瓦德 (Alexander Osterwalder) 和伊夫·皮尼厄 (Yves Pigneur) 在他们颇具影响力的著作《商业模式新生代》(Business Model Generation) 中提出了一种可视化技术，这本书非常值得开发人员阅读，也非常容易理解。商业模式画布非常有用，因为它将商业模式分解为九个构建模块，如图 2.4所示，该图展示了一家在线体育器材供应商的商业模式画布示例。

One of the best ways to learn about a company’s business model is to visualize it using a Business Model Canvas; a visualization technique introduced by Alexander Osterwalder and Yves Pigneur in their influential book, “Business Model Generation” highly recommended and very accessible reading for developers. A Business Model Canvas is extremely useful because it breaks down a business model into nine building blocks, as shown in Figure 2.4 which illustrates an example Business Model Canvas for an online sports equipment provider.

了解商业模式的九大基石，就能让你了解哪些因素对企业至关重要。关键信息包括：商业模式如何盈利、最重要的资产是什么，以及至关重要的目标客户。下文将逐一介绍商业模式的各个组成部分。欲了解更多信息，《商业模式新生代》一书是理想的学习资源。

Understanding the nine building blocks of a business model tells you what is important to the business. Key information like: how it makes money, what its most important assets are, and crucially its target customers. Each of the sections of a business model is introduced below. For more information, the “Business Model Generation” book is the ideal learning resource.

• 客户细分——企业所针对的不同类型的客户。例如利基市场、大众市场和企业对企业 (B2B)。
• Customer Segments—the different types of customers a business targets. Examples include niche markets, mass markets, and business-to-business (b2b).
• 价值主张——企业向客户提供的产品或服务。例如实体商品和云托管。
• Value Propositions—the products or services a business offers to its customers. Examples include physical goods and cloud hosting.
• 渠道——企业向客户交付产品或服务的方式。例如实体运输和网站。
• Channels—how the business delivers its products or services to customers. Examples include physical shipping and a website.
• 客户关系——企业与各个客户群体之间的关系类型。例如，直接的个人协助和自动化电子帮助设施。
• Customer Relationships—the types of relationships the business has with each customer segment. Examples include direct personal assistance and automated electronic help facilities.
• 收入来源——企业盈利的不同方式。例如广告收入和定期订阅费。
• Revenue Streams—the different ways the business makes money. Examples include advertising revenue and recurring subscription fees.
• 关键资源——企业最重要的资产。例如知识产权和重要员工。
• Key Resources—a business’s most important assets. Examples include intellectual property and important employees.
• 关键活动——确保业务正常运转的基础活动。例如软件开发和数据分析。
• Key Activities—the activities fundamental to making the business work. Examples include developing software and analyzing data.
• 关键合作伙伴——企业最重要的合作伙伴列表。例如供应商和顾问。
• Key Partnerships—a list of the business’s most significant partners. Examples include suppliers and consultants.
• 成本结构——企业产生的成本。例如工资、软件订阅和库存。
• Cost Structure—the costs that the business incurs. Examples include salaries, software subscriptions, and inventory.

掌握商业模式画布提供的信息后，您将能够向领域专家提出有意义的问题，并帮助推动业务发展，而不仅仅是技术实现。寻找和理解雇主的商业模式，哪怕只是小小的努力，也是值得的。

Armed with the information presented by a Business Model Canvas you will be empowered to ask meaningful questions of domain experts and help to drive the evolution of the business—not just the technical implementation. The small effort of finding and understanding your employer’s business model is well worth it.

故意发现

Deliberate Discovery

BDD 的创始人 Dan North 发表了一种提升领域知识的方法，名为“深思熟虑的发现”（http://dannorth.net/2010/08/30/introducing-deliberate-discovery/）。与其在规划和需求收集阶段（例如规划扑克和故事创作活动）专注于敏捷方法的框架，不如花时间学习问题领域中你不了解的部分。Dan 指出：“无知是提高吞吐量的最大障碍。” 因此，更丰富的领域知识将提升你的建模工作。

Dan North, the creator of BDD, has published a method for improving domain knowledge called deliberate discovery (http://dannorth.net/2010/08/30/introducing-deliberate-discovery/). Instead of focusing on the framework of agile methodologies during planning and requirement gathering stages, such as the activities of planning poker and story creation, you should devote time to learning about areas of the problem domain that you are ignorant about. Dan states that “Ignorance is the single greatest impediment to throughput.” Therefore a greater amount of domain knowledge will improve your modeling efforts.

在项目开始时，团队应该齐心协力，找出问题领域中他们最不了解的部分，以确保在知识消化会议期间解决这些问题。团队应该利用知识消化会议来识别未知的未知部分，即他们尚未发现的领域部分。这项工作应该由领域专家和利益相关者主导，他们可以帮助团队专注于重要领域，而不是简单地消化知识。整个问题领域。这将使团队能够识别领域知识的差距并快速处理它们。

At the start of a project teams should make a concerted effort to identify areas of the problem domain that they are most ignorant of to ensure that these are tackled during knowledge-crunching sessions. Teams should use knowledge-crunching sessions to identify the unknown unknowns, the parts of the domain that they have not yet discovered. This should be led by the domain experts and stakeholder who can help the teams focus on areas of importance and not simply crunching the entire problem domain. This will enable teams to identify the gaps in domain knowledge and deal with them in a rapid manner.

模型探索漩涡

Model Exploration Whirlpool

领域驱动设计的创始人 Eric Evans 创建了一份名为“模型探索漩涡”（http://domainlanguage.com/ddd/whirlpool/）的草稿文档。该文档介绍了一种建模和知识挖掘方法，可以作为其他敏捷方法的补充，并可在应用程序开发生命周期的任何时候调用。它并非作为一种建模方法，而是用于在模型创建过程中遇到问题时使用。诸如与业务部门沟通中断、解决方案设计过于复杂，或者完全缺乏领域知识等迹象，都会促使人们进入“模型探索漩涡”中定义的流程，并挖掘领域知识。

Eric Evans, the creator of Domain-Driven Design, has created a draft document named the Model Exploration Whirlpool (http://domainlanguage.com/ddd/whirlpool/). This document presents a method of modeling and knowledge crunching that can complement other agile methodologies and be called upon at any time of need throughout the lifetime of application development. It is used not as a modeling methodology but rather for when problems are encountered during the creation of a model. Telltale signs such as breakdowns in communication with the business and overly complex solution designs or when there is a complete lack of domain knowledge are catalysts to jump into the process defined in the Model Exploration Whirlpool and crunch domain knowledge.

漩涡浴包含以下活动：

The whirlpool contains the following activities:

• 场景探索

  领域专家会描述团队在问题领域中担心或遇到困难的场景。场景是指一系列对领域专家来说很重要的步骤或流程，是应用程序的核心，并且属于项目范围之内。领域专家使用团队能够理解的具体示例解释了场景后，团队会将场景绘制成图，就像在开放空间中以可视化的方式进行事件风暴一样。

• Scenario Exploring

  A domain expert describes a scenario that the team is worried about or having difficulty with in the problem domain. A scenario is a sequence of steps or processes that is important to the domain expert, is core to the application, and that is within the scope of the project. Once the domain expert has explained the scenario using concrete examples the team understands, the group then maps the scenario, like event storming in a visual manner in an open space.

• 造型

  在运行场景的同时，团队开始检查当前模型并评估其对于解决领域专家所表达的场景的有用性。

• Modeling

  At the same time of running through a scenario, the team starts to examine the current model and assesses its usefulness for solving the scenario expressed by the domain expert.

• 挑战模型

  一旦团队修改了模型或创建了新模型，他们就会用领域专家的进一步场景来挑战它，以证明其有用性。

• Challenging the Model

  Once the team has amended the model or created a new model they then challenge it with further scenarios from the domain expert to prove its usefulness.

• 收获和记录

  有助于演示模型的重要场景应该记录在文档中。关键场景将构成参考场景，用于演示模型如何解决问题域中的关键问题。业务场景的变化频率低于模型，因此，收集一些重要的场景作为模型更改时的参考会很有帮助。但是，不要试图记录每个设计决策和每个模型；有些想法应该留在绘图板上。

• Harvesting and Documenting

  Significant scenarios that help demonstrate the model should be captured in documentation. Key scenarios will form the reference scenarios, which will demonstrate how the model solves key problems within the problem domain. Business scenarios will change less often than the model so it is useful to have a collection of important ones as a reference for whenever you are changing the model. However, don’t try and capture every design decision and every model; some ideas should be left at the drawing board.

• 代码探测

  当对问题领域的洞察被解锁并且设计取得突破时，技术团队应该在代码中证明它以确保它可以实现。

• Code Probing

  When insight into the problem domain is unlocked and a design breakthrough occurs the technical team should prove it in code to ensure that it can be implemented.

超越需求

Look Beyond Requirements

警惕业务用户对现有软件增强功能的要求，因为他们通常会根据当前系统的限制而不是他们真正的需求提出要求。问问自己，你有多少次与用户沟通，真正了解了需求背后的动机。你是否理解了需求背后的原因？一旦你分享并了解了客户的真正需求，你通常可以提出更好的解决方案。当你这样与客户沟通，紧接着是经典台词：“哦，真的吗？我不知道你还能这样做！”时，客户通常会感到惊讶。记住：你是推动者。不要盲目遵循用户的需求。业务用户可能无法编写有效的功能或有效地表达目标。你必须分享和理解潜在的愿景，并了解企业想要实现的目标，这样你才能提供真正的商业价值。

Be wary of business users asking for enhancements to existing software, because they will often give you requirements that are based on the constraints of the current systems rather than what they really desire. Ask yourself how often you have engaged with a user to really find the motivation behind a requirement. Have you understood the why behind the what? Once you share and understand the real needs of a customer, you can often present a better solution. Customers are usually surprised when you engage them like this, quickly followed by the classic line: “Oh, really? I didn’t know you could do that!” Remember: You are the enabler. Don’t blindly follow the user’s requirements. Business users may not be able to write effective features or effectively express goals. You must share and understand the underlying vision and be aware of what the business is trying to achieve so you can offer real business value.

把握领域愿景，对核心达成共识

Capture the Domain Vision for a Shared Understanding of What Is Core

在开始任何产品合作之前，务必要求提供项目概述。在任何大型组织中，项目启动过程早在开发团队参与之前就已开始。公司通常会准备一份简短的论文，解释为什么公司希望为这个项目开发软件而不是其他项目。这份论文往往是核心领域的关键所在。它论证了为什么开发这个软件是一个好主意；仔细研究这份论文，找出重点。将要点写在白板上，让团队所有成员都明白他们为什么要开发这个软件。

Before embarking on any product engagement, always ask for a project overview. In any large organization, the process of project inception starts long before the development team gets involved. Often there will be a small paper on why the company wants to build the software for this initiative over another. This paper often holds the key to the core domain. The paper is a justification on why writing the software is a good idea; study this and pick out what is important. Make it explicit by writing the salient points on the whiteboard so all on the team understand why they are writing the software.

在项目开始时，可​​以创建一个领域愿景声明，明确阐述软件成功的核心要素、业务目标以及价值所在。这条信息应该与团队共享，甚至可以贴在办公室的墙上，提醒大家编写这款软件的初衷。

A domain vision statement can be created at the start of a project to explicitly capture what is central to the success of the software, what the business goal is, and where the value is. This message should be shared with the team and even stick it up on a wall in the office as a reminder to why the software is being written.

提炼问题域

Distilling a Problem Domain

以在线拍卖网站的领域模型为例，如图 3.2所示。这个庞大的整体系统由许多不同的组件组成。有些部分在任何在线系统中都能找到，但有些部分则是该领域和特定业务所独有的。

Take the domain model of an online auction site, as shown in Figure 3.2. There are many different components that make up the large overall system. Some parts will be found in any online system, but some will be unique to the domain and specific business.

图 3.3展示了如何将大型问题域划分为子域。会员系统负责处理会员的注册、偏好设置和详细信息。卖家系统负责处理卖家活动的所有流程和行为。拍卖系统负责管理拍卖时间和处理竞价活动。商品列表系统负责拍卖网站上可供出售的商品目录。最后，争议解决系统负责处理会员和卖家之间的争议。

Figure 3.3 shows how the large problem domain is partitioned into subdomains. Membership represents the area of the systems that deals with the registrations, preferences, and details of members. The seller partition represents all the processes and behaviors that deal with seller activities. Auction is the area of the problem domain that deals with managing the timing of auctions and dealing with bid activity. Listings are the catalogues of items that are available on the auction site. Finally, the dispute resolution domain deals with disputes between members and sellers.

与领域专家进行交流后，知识的提炼应该能够揭示出您即将创建的应用程序的独特之处和重要性。您可以将子域划分为核心域、通用域和支持域，如图3.4所示。

The distillation of knowledge after sessions with domain experts should reveal what’s unique and important about the application you are about to create. You can separate the subdomains into core, generic, and supporting domains, as shown in Figure 3.4.

在图 3.4中，您可以看到在线拍卖网站的核心域是卖家域和拍卖域。卖家域包含卖家的评级和确定卖家费用的域逻辑。拍卖核心域是运行拍卖和处理竞价的机制。这两个领域对于拍卖网站的成功都至关重要。会员域和列表域通过为竞标者提供创建帐户的机会来支持核心域。并查找待售商品。争议解决领域是通用的，因为它可以使用现成的商业软件包来提供服务；在这种情况下，它仅仅是一个处理客户争议案件的滴答系统。

In figure 3.4 you can see that the core domains of the online auction site are the seller and the auction. The seller domain contains the ratings for a seller and the domain logic for determining seller fees. The auction core domain is the mechanism for running an auction and handling bids. Both of these areas are vital for the success of the auction site. The membership and listing domains support the core domains by providing bidders the opportunity to create accounts and find items for sale. The dispute resolution domain is generic in that it can be served using a commercial off-the-shelf package; in this scenario it is merely a ticking system to handle customer dispute cases.

要知道在哪里投入最多的精力和质量，关键在于了解核心领域在哪里，因为这些领域是软件成功的关键。这些知识是通过与领域专家合作进行知识梳理会议提炼出来的，旨在了解正在开发的产品的最重要方面。

To know where to invest the most effort and quality, it’s crucial to understand where the core domains are, because these are key to making the software successful. This knowledge is distilled from knowledge-crunching sessions working in collaboration with domain experts to understand the most important aspect of the product under development.

核心领域

Core Domains

要了解你的企业要求你开发的产品的核心是什么，你需要问自己一些问题。产品的哪些部分能够使其成功？为什么这些系统部分如此重要？为什么它们不能直接购买？换句话说，是什么让你的系统值得构建？

To understand what’s core to the product that your business is asking you to develop, you need to ask yourself some questions. What are the parts of the product that will make it a success? Why are these parts of the system important? And why can’t they be bought off the shelf? In other words, what makes your system worth building?

系统的核心部分代表了贵公司通过交付该软件所能获得的基本竞争优势。核心部分并不总是显而易见的。

The core parts of the system represent the fundamental competitive advantage that your company can gain through the delivery of this software. What’s core is not always obvious.

如果说通用领域应该被引入，并且几乎不进行开发，那么核心领域则恰恰相反。核心领域需要你最好的开发人员——或者说，你的“突击队员”。核心领域或许不会占据公司技术的最大份额，但它们需要的投资最多。

If the generic domains should be brought in and have little development, the core domain is the polar opposite. The core domains require your best developers—your commandos, if you will. The core domains may not make up the lion’s share of your company’s technology, but they require the most investment.

核心是什么当然会随着时间而变化。如果你成功了，竞争对手就会效仿，所以核心领域必须不断发展，才能使你的业务脱颖而出，保持领先地位。开发团队必须考虑到这一点，并确保它与软件和业务的价值相一致。

What is core certainly changes over time. If you are successful, competitors mimic, so the core domain must evolve to set your business apart from the rest and keep it ahead of the game. It’s vital that the development team take this on board and ensure it is in synergy with the values of the software and the business.

将您的核心域视为产品而不是项目

Treat Your Core Domain as a Product Rather Than a Project

无论是开发团队还是业务团队，在为复杂核心领域编写软件时，都需要在思维方式上做出根本性的转变，那就是专注于产品本身，而不是将其视为一个独立的项目。通常，商业产品的软件开发永远不会结束；相反，开发中的产品会经历功能增强的阶段。软件会持续投入，直到它不再为业务提供价值，或者无法通过进一步的修改来丰富。

One of the fundamental shifts in mentality required for writing software for complex core domains, from both the development team and the business, is to focus on the product rather than view it as a standalone project. Often, the development of software for a business product is never finished; instead, the product under development will live through periods of feature enhancements. The software is invested in until it is no longer providing value for the business or it can’t be enriched with further modifications.

您的产品是一个不断发展变化、功能增强和调整的体系。正如开发人员不断迭代一样，业务也在不断更新。一个好的想法会随着时间的推移而不断改进和充实，最终变得更好。了解您正在开发的产品的价值以及它能为公司带来的投资回报率 (ROI)。与您的业务赞助商讨论产品的未来发展，这有助于您集中精力进行编码工作；了解对他们来说什么是重要的。

Your product is an evolving succession of feature enhancements and tweaks. Just as developers iterate, so, too, does the business. A good idea becomes better after it is improved upon and fleshed out over time. Understand the value of the product you are working on and what return on investment (ROI) it brings to the company. Talk to your business sponsors about the future of the product to help focus your coding efforts; know what is important to them.

很多时候，企业核心领域的软件并不被视为需要精心呵护的产品。相反，商业软件为了快速上市而牺牲了质量和长期投入。人们过于注重项目本身和迫在眉睫的截止日期，而忽略了对产品未来的投资。这导致代码库难以维护和增强，并陷入了“大泥球”（BBoM）的架构模式，正如第一章“什么是领域驱动设计？”中所讨论的那样。

All too often, software for the core domain of a business isn’t viewed as a product that requires care and attention. Instead, business software sacrifices quality and long-term investment for speed to market. Too much emphasis is placed on thinking about the project and looming deadlines, rather than investing in the product for the future. This results in a codebase that is hard to maintain and enhance, and falls into the architectural pattern of the Big Ball of Mud (BBoM), as discussed in Chapter 1, “What Is Domain-Driven Design?”

然而，另一方面，发布日期的延长往往是不可避免的，因为其他商业利益也取决于软件的发布日期。解决这一困境的方法是精简功能范围，以保持高质量并按时完成交付。为了做到这一点，您必须理解并分享软件预期实现的愿景和最终目标。这种理解使您能够只包含产品中最重要的功能，并确保其能够提供企业期望的价值。

The flip side, however, is a prolonged release date, which is often nonnegotiable if other business interests depend on the launch date of the software. The solution to this quandary is to look to descope features to keep quality high and the deadline on track. To be in a position to do this, you must understand and share the vision and ultimate goal that the software is expected to meet. This understanding enables you to include only the most important features of the product and ensure that it delivers the value the business expects.

通用域名

Generic Domains

通用域名是许多大型业务系统都拥有的子域名。例如，电子邮件发送服务、帐户软件包或报表套件。这些子域名并非业务的核心，但业务运营离不开它们。由于这些子域名并非核心，也不会给您带来竞争优势，因此花费大量精力或投资来构建它们并不合理。您可以考虑购买通用域名的软件。或者，您可以聘请初级开发人员来构建这些系统，从而腾出更多经验丰富的资源来处理业务的核心工作。

A generic domain is a subdomain that many large business systems have. An example of a generic domain is an e-mail sending service, an accounts package, or a report suite. These subdomains aren’t core to the business, but the business can’t operate without them. Because these subdomains aren’t core and won’t give you a competitive edge, it doesn’t make sense to spend a lot of effort or investment in building them. Instead, look to buy in software for generic domains. Alternatively, use junior developers to build these systems, freeing up more experienced resources to work on what’s core to your business.

然而，需要注意的是，像 Groupon 或 Wowcher 这样以沟通和限时优惠定向邮件为特色的企业，其核心领域可能就是复杂的电子邮件/CRM 系统。一家企业的核心功能，对另一家企业来说可能也是通用的。

Note, however, that a business defined by communication and targeted e-mails on limited-time offers, like a Groupon or a Wowcher, could have its core domain as a sophisticated e-mail/CRM system. What is core to one business may well be generic to another.

支持域

Supporting Domains

系统中剩余的子域被定义为支持域。这些子域虽然不定义系统功能，但有助于支持核心域。例如，亚马逊的支持域是允许客户浏览产品目录的功能。亚马逊的产品浏览功能并不能将其定义为一家公司，也与其他任何电商网站并无太大区别，但它确实支持跟踪用户旅程以提供推荐引擎。

The remaining subdomains in the system are defined as the supporting domains. These are subdomains that, although not defining what your system does, help to support your core domains. For example, Amazon’s supporting domains would be the functionality that enables a customer to browse a catalog for products. Amazon’s product-browsing functionality doesn’t define it as a company, and neither is it that different from any other e-commerce site, but it does support the tracking of user journeys to feed a recommendations engine.

与通用域一样，如果可能的话，您应该考虑购买现成的解决方案。如果做不到，请不要在这些系统上投入大量资金；它们需要工作，但不需要您长时间关注。需要注意的是，您并不总是需要为支持域实施技术解决方案。也许手动流程可以满足业务需求，而开发人员可以专注于核心域。

As with the generic domains, if possible, you should look to buy off-the-shelf solutions. Failing that, do not invest heavily in these systems; they need to work but do not require your prolonged attention. It’s important to note that you may not always need to implement a technical solution to a supporting domain. Perhaps a manual process could meet the needs of the business while developers focus on the core domain.

关注清晰的边界而非完美的模型

Focus on Clean Boundaries Over Perfect Models

大泥球模式是最流行的软件架构模式。在经过长期演进的大型软件系统中，系统中很可能存在一些不完善的地方。如果应用程序中的某些区域与大泥球模式类似，那么最好的办法就是在这些区域周围设置边界，以防止泥球蔓延到应用程序的其他区域。图 3.6展示了一个应用程序的解决方案空间，该应用程序在旧版大泥球模式和新模型之间定义了明确的边界。可以使用防腐层来防止一个模型模糊地融入另一个模型。

The Big Ball of Mud pattern is the most popular software architectural pattern. In large-scale software systems that have evolved over time there are more than likely areas of the system that are not perfect. If you have areas of an application that resemble the BBoM pattern then the best thing to do is to put a boundary around them to prevent the mud spreading into new areas of the application. Figure 3.6 shows the solution space of an application that has defined explicit boundaries between the legacy BBoM and the new models. An anti-corruption layer can be used to prevent one model blurring into another.

核心领域并不总是必须第一次就完美

The Core Domain Doesn’t Always Have to Be Perfect the First Time

在理想情况下，高质量的软件始终是您的首要任务；然而，务实也很重要。有时，新系统的核心领域可能是第一个进入市场的，有时企业可能无法判断某个特定想法是否会成功并成为其成功的核心。在这种情况下，企业希望快速学习，快速失败，而无需投入大量的前期精力。

In an ideal world, quality software would always be top of your agenda; however, it’s important to be pragmatic. Sometimes a new system’s core domain could be first to market, or sometimes a business may not be able to tell if a particular idea will be successful and become core to its success. In this instance, the business wants to learn quickly and fail fast without putting in a lot of up-front effort.

如果产品的第一个版本未被业务部门充分理解，那么它可能不会被精心设计。这很正常，因为业务部门不确定是否会长期投入，开发团队应该理解为什么业务部门更看重交付速度而不是灵活的设计。但是，如果产品成功了，并且长期投资软件是有价值的，那么就需要进行重构以支持后续的演进；否则，匆忙交付所积累的技术债务就会开始成为一个问题。

The first version of a product that is not well understood by the business may not be well crafted. This is fine, because the business is unsure if it will be invested in over time, and the development team should understand why the business wants speed of delivery over supple design. However, if the product is a success and there is value in a prolonged investment in the software, you need to refactor to support the evolution; otherwise, the technical debt racked up in the rush to deliver starts to become an issue.

构建子域名是为了替换而不是重复使用

Build Subdomains for Replacement Rather Than Reuse

在子域中开发模型时，请尝试独立构建它们，并考​​虑替换。使用清晰的边界，将它们与其他模型、遗留代码和第三方服务区分开。通过以替换而非重用为目标进行编码，您可以创建足够好的支持子域，而无需浪费精​​力去完善它们。将来，它们可以被现成的解决方案取代，或者可以根据业务需求的变化进行重写。

When developing models in subdomains try and build them in isolation with replacement in mind. Keep them separated from other models, legacy code, and third party services by using clean boundaries. By coding for replacement rather than reuse you can create good enough supporting subdomains without wasting effort on perfecting them. In the future they can be replaced by off-the-shelf solutions or can be rewritten as business needs change.

领域与领域模型

The Domain versus the Domain Model

领域代表您正在处理的问题领域。它是情况的确切现实。另一方面，领域模型是问题领域的抽象，以代码实现的形式表示，它代表问题的视图，而不是现实。图 4.2突出显示了这种差异。领域模型的用处在于它能够表示领域中复杂的逻辑和策略以解决业务问题，而不是它如何很好地反映现实。它也存在于一个更抽象的空间中：团队使用的语言和绘制的图表。该模型建立在开发团队和业务团队的协作之上。专家。该模型仅包含与正在创建的应用程序上下文中解决问题相关的内容。它需要随着业务不断发展，以保持其实用性和有效性。领域模型的存在只是为了帮助我们解决问题；为了有效，它需要清晰且不受技术复杂性的影响。这样，业务团队和开发团队就可以协作进行设计。

The domain represents the problem area you are working within. It is the firm reality of the situation. The domain model, on the other hand, is an abstraction of the problem domain, expressed as a code implementation that represents a view, not the reality, of the problem. This difference is highlighted in Figure 4.2. The usefulness of the domain model comes in its ability to represent complex logic and polices in the domain to solve business problems and not how well it reflects reality. It also exists in a more abstract space: in the language the team speaks and the diagrams it sketches. The model is built from the collaboration between the development team and the business experts. The model contains only what is relevant to solve problems in the context of the application being created. It needs to constantly evolve with the business to keep itself useful and valid. The domain model only exists to help us solve problems; in order to be effective it needs to have clarity and be free of technical complexities. This way both the business and development teams can collaborate on its design.

分析模型

The Analysis Model

分析模型有时也称为业务模型，是描述系统模型的一系列工件的集合。这些工件可以是任何东西，从香烟包装草图到非正式的UML。分析模型的存在是为了帮助开发团队和业务用户理解问题领域；它不是技术实现的蓝图。

Also sometimes known as a business model, an analysis model is a collection of artifacts that describe the model of a system. These artifacts can be anything from cigarette packet sketches to informal UML. The analysis model exists to help both the development teams and business users to understand the problem domain; it is not a blueprint for the technical implementation.

代码模型

The Code Model

DDD 并不主张移除分析模型。远非如此，因为描述系统的模型本身就蕴含着巨大的价值。相反，DDD 强调需要保持代码模型（即实现）与分析模型（即设计）紧密协同。这种协同是通过确保两个模型都得到描述并共享 UL（工作流框架）来实现的，如图 4.3所示。理想中的模型是一个在实现和设计中都有价值的单一模型。为了实现这一点，至关重要的是要使代码模型摆脱技术顾虑，专注于领域。反过来，拥有一个可实现的分析模型也很重要——它不能太抽象或太高级而无用。

DDD doesn’t advocate the removal of the analysis model. Far from it, because there is much value to be gained from a model that describes the system. Instead, DDD emphasizes the need to keep the code model, the implementation, in close synergy with the analysis model, the design. This synergy is achieved by ensuring both models are described and share the UL, as shown in Figure 4.3. The utopia is a single model that has value in both implementation and design. To achieve this, it is crucial to keep the code model clean of technical concerns and focused on the domain. In turn, it is important to have an analysis model that can be implemented—not too abstract or high level to be of any use.

代码模型是领域模型的主要表达

The Code Model Is the Primary Expression of the Domain Model

代码模型是分析模型的实现；它验证业务假设，并快速突出显示与分析模型不一致之处。如果在代码模型创建过程中发现问题，且逻辑似乎不符，开发团队应与领域专家合作解决这些问题。代码模型的更新会通过修改工作流程和策略（这些修改之前可能并未暴露问题）反映在分析模型中。同样，任何来自业务视角的变更都需要反映在代码模型中。代码和业务模型应保持协同。代码即模型；代码即真相。

The code model is the realization of the analysis model; it validates the assumptions of the business and quickly highlights any inconsistencies with the analysis model. If, during the creation of the code model, issues are found and logic doesn’t seem to fit, the development team should work with the domain experts to resolve these problems. This update to the code model is reflected in the analysis model by making changes to work flow and polices that may not have exposed issues before. Likewise, any changes from a business perspective need to be reflected in the code model. The code and business models are kept in synergy. The code is the model; the code is the truth.

前期设计面临的挑战

The Challenges with Upfront Design

过去，软件系统需求的获取被视为一项早在编码开始之前就已进行的活动。业务专家会与业务分析师沟通，业务分析师再与架构师沟通，架构师会根据问题领域的所有信息生成分析模型。之后，该分析模型会连同线框图和工作流程图一起交给开发人员，以便他们构建系统。

Historically, the capturing of requirements for software systems was seen as an activity that could occur long before coding was due to start. Business experts would talk to business analysts, who in turn would talk to architects, who would produce an analysis model based on all the information from the problem domain. This analysis model would then be handed over to the developers, along with wireframes and work flow diagrams, so they could build the system

当开发人员开始用代码实现分析模型时，他们常常会发现架构师生成的高级工件与系统构建的实际情况不匹配。然而，在这个阶段，开发人员通常缺乏与业务人员和架构师沟通的反馈回路，因此无法更新分析模型并采纳他们的意见。相反，开发人员偏离了分析模型，他们的实现常常会忽略重要的、描述性的领域术语和概念，而这些术语和概念本可以提供对领域的更深入的洞察和理解。

As developers start to implement the analysis model in code, they often find a mismatch between the high-level artifacts produced by architects and the reality of building the system. However, at this stage there is often no feedback loop for developers to talk to the business and architects, so the analysis model can be updated and their input enacted. Instead, the developers diverge from the analysis model, and their implementation often overlooks important and descriptive domain terms and concepts that would have provided deeper insight and understanding of the domain.

随着开发团队逐渐脱离分析模型，它的作用也越来越小。由于开发团队专注于抽象技术问题而非业务概念，对模型的关键洞察逐渐丧失。最终，工作完成了，但代码却没有反映原始分析模型的正确性。业务部门仍然认为原始分析模型是正确的，并且没有意识到代码模型内部的变更。

As the development team further evolves away from the analysis model, it becomes less and less useful. Crucial insight into the model is lost as the development team focuses on abstracting technical concerns instead of business concepts. In the end the job gets done, but the code bears no reflection to the original analysis model. The business still believes the original analysis models are correct and is unaware of the alterations within the code model.

图 4.4显示了如果开发团队不参与领域知识的处理，分析模型和代码模型会如何相互分歧。

Figure 4.4 shows how the analysis and code models can diverge from each other if the development team is not involved in domain knowledge crunching.

当代码库后续的增强难以实现时，问题就暴露出来了。困难在于业务专家和开发人员对业务的理解不同。代码与业务流程缺乏协同，并且缺乏丰富的领域知识。

The problem is revealed when later enhancements to the codebase are difficult to implement. The difficulties are due to the business experts and developers having different models of the business. The code doesn’t have a synergy with the business processes and is not rich in domain knowledge.

团队建模

Team Modeling

DDD 建议采用一种更具协作性的方法来捕获系统需求并理解现有工作流程。重点在于整个团队，业务专家和架构师（只要他们参与编程）将围绕问题空间展开讨论。讨论内容可以涵盖与相关系统相关的任何文档或遗留代码。协作式知识交流会议的理念是让开发人员、测试人员、业务分析师、架构师和业务专家作为一个统一的团队协同工作。这使得开发人员和测试人员能够了解领域术语背后的含义，并理解问题领域中的复杂逻辑。它还使业务专家能够体验所使用的建模技术。理解建模后，业务专家将能够与开发团队一起建模和验证设计。

DDD suggests a more collaborative method of capturing system requirements and understanding existing work flow. Emphasis is placed on the entire team, with business experts and architects (as long as they code) having discussions around the problem space. Discussions can include any documentation or legacy code that is related to the system in question. The idea behind the collaborative knowledge-crunching sessions is for the developers, testers, business analysts, architects, and business experts to work as a unified team. This enables the developers and testers to learn about the meaning behind domain terms, and understand complex logic in the problem area. It also enables business experts to experience the modeling techniques employed. With an understanding of modeling, business experts will themselves be able to model and validate designs with the development team.

信息共享使业务专家能够参与软件设计，并为开发团队提供更深入的领域洞察和理解。一段时间后，开发人员和业务专家将收集相关信息，构建问题领域的初始模型。我们将使用领域场景（即该领域的实际问题）来测试该初始模型，以验证其有效性。使用模型的术语和语言进行“大声建模”也有助于验证早期设计。

The sharing of information enables business experts to contribute to the software design, and provides a deeper insight and understanding of the domain to the development team. After a period of time, developers and business experts will discover the relevant information to build an initial model of a problem domain. This initial model is put to the test by using domain scenarios: real problems of the domain to validate its usefulness. Modeling out loud, using the terms and language of the model, can also help to validate early designs.

共同建模的重要方面在于开发团队能够持续获得来自业务专家的反馈。这有助于发现重要的概念，并帮助团队了解哪些概念不重要，可以从模型中剔除。会议中的突破体现为简单的抽象，这些抽象能够阐明复杂的领域概念，并最终构建更具表现力的模型。

The important aspect of modeling together is the constant feedback the development team gets from the business experts. This leads to the discovery of important concepts and allows the team to understand what is not important and can be excluded from the model. Breakthroughs in sessions are manifested as simple abstractions that clarify complex domain concepts and lead to a more expressive model.

然后，该模型以代码形式表达，团队和业务专家可以通过软件的早期版本快速获得反馈。反馈反过来又能激发更深入的洞察，这可以反映在代码和分析模型中，如图4.5所示。

The model is then expressed in code and the team, along with business experts, can gain fast feedback with early versions of software. Feedback in turn fuels deeper insight, which can be reflected in the code and analysis models, as highlighted in Figure 4.5.

在每次迭代中，开发团队成员可能会发现模型中一些他们认为有用且可以解决问题但在实施过程中必须修改的部分。这些知识会被反馈给业务专家，以便他们澄清问题，并完善他们对问题领域的理解。在这个过程中，代码模型和分析模型是一体的，其中一个模型的变更会导致另一个模型的变更。

During each iteration, the development team members may come across parts of the model that they thought were useful and could solve a problem but during implementation had to change. This knowledge is fed back to the business experts for clarification and to refine their own understanding of the problem domain. In this process, the code model and analysis model are one, and a change in one will result in a change to the other.

图 4.6显示了分析和代码模型在产品创建过程中如何协同作用并作为一个整体发展。

Figure 4.6 shows how the analysis and code model are in synergy and evolve as one during the creation of a product.

语言的寿命将超过你的软件

A Language Will Outlive Your Software

创建 UL 的实用性远不止应用于当前正在开发的产品。它有助于明确定义业务内容，更深入地洞察业务流程和逻辑，并改善业务沟通。

The usefulness of creating a UL has an impact that goes beyond its application to the current product under development. It helps define explicitly what the business does, it reveals deeper insights into the process and logic of the business, and it improves business communication.

商业语言

The Language of the Business

我最近和妻子一起去买窗帘。褶皱、垂长、衬布——这些术语在窗帘制作领域都有着特定的意义。店里的员工可能会花几个小时来描述他们想要什么，但这可能会导致含义模糊。不过，由于员工们使用的是窗帘店领域的术语，所以对话会保持简短精炼，每个懂这个领域的人都能理解这些术语的含义。

I recently went curtain shopping with my wife. Pleated, hang length, interlining—these were all terms that meant something specific in the domain of curtain makers. Employees in the shop could spend hours describing what they wanted, but that could lead to ambiguity in meaning. But because the employees use terms in the domain of the curtain shop, conversations are kept short and concise, and everybody who understands the domain understands their meanings.

木匠、金融交易员、军人以及几乎所有你能想到的领域都是如此。每个领域都有各自独特的术语和概念。秘密语言能够让复杂的主题以简洁明了的对话形式进行讨论，而无需令人困惑的胡言乱语。对于开发团队来说，理解并协作使用这种被称为“通用语言”（UL）的语言至关重要。UL 的术语和概念用于与团队成员（包括领域专家）沟通。它们也用于命名代码库中的类、方法和命名空间。

It’s the same with carpenters, financial traders, the military, and nearly every domain you can imagine. Each has terms and concepts that mean something very particular to them. A secret language enables complex topics to be covered in concise and meaningful dialogue without the need for confusing babble. It’s vital for a development team to understand and collaborate on this language, known as the ubiquitous language (UL). The UL’s terms and concepts are used when communicating with team members, including domain experts. They’re also used to name classes, methods, and namespaces in the codebase.

开发者和企业之间的翻译

Translation between the Developers and the Business

商业语言是一种丰富的方言，其术语描述性强且富有洞察力。然而，如果开发团队没有与领域专家合作，无法充分理解该语言并将其应用于代码实现，那么它的大部分优势就会丧失。开发人员反而会针对问题领域创建自己的语言和抽象概念集。如果没有共享的模型和实践语言（UL），开发团队与领域专家之间的有效沟通将面临挑战，需要某种形式的翻译。从领域概念到技术概念的翻译可能非常耗时且容易出错。当代码实现团队使用的模型与领域专家的模型不同时，重要的领域洞察力可能会丢失。此外，团队需要进行冗长而复杂的沟通来解释软件实现中遇到的问题，而这些问题本可以通过更好地理解问题领域并采用更有效的沟通方式轻松解决。

The business language is a rich dialect with highly descriptive and insightful terminology. However, if the development team doesn’t engage with domain experts to fully understand the language and use it within the code implementation, much of its benefit is lost. Developers instead create their own language and set of abstractions for a problem domain. Without a shared model and UL, effective communication between the development team and domain experts is a challenge and requires some form of translation. Translation from domain concepts to technical concepts can be time consuming and error prone. Vital domain insights can be lost when the team implementing the code is using a different model than that of the domain expert. Furthermore, lengthy and convoluted communication is required to explain problems that the team faces in a software implementation that could be solved easily with a better understanding of the problem domain and a more efficient way of communicating.

图 4.7展示了开发人员思维中的不同模型如何导致与领域专家的沟通出现问题。在代码中，开发人员专注于技术抽象、设计模式和设计原则，而领域专家则专注于业务流程和工作流。

Figure 4.7 shows how a different model in the minds of a developer can make communication with the domain expert problematic. In the code, the developer is focused on technical abstractions, design patterns, and design principles, whereas the domain expert is focused on business process and work flow.

开发人员应该用领域术语和概念来思考，而不是技术术语，以避免将业务术语翻译成技术术语。如果开发团队在翻译复杂的逻辑和工作流程时犯了错误，那么代码中出现 bug 的可能性就会大大增加。

Developers should think in domain terms and concepts, not technical terms, to avoid the need to translate from business jargon into technical jargon. If the development team makes a mistake when translating complex logic and work flow, the chance of creating a bug in code significantly increases.

通过具体的例子来创造一种语言

Carving Out a Language by Working with Concrete Examples

正如第 2 章“提炼问题域”中提到的，为了更好地理解你所在的领域，最好采取领域行为的具体示例。真实场景的具体示例有助于巩固领域内的流程和概念。然而，重要的是揭示业务流程的意图，而不是具体实现。只用业务术语进行讨论，不要涉及技术细节。

As mentioned in Chapter 2, “Distilling the Problem Domain,” to better understand the domain you’re in, it’s a good idea to take specific examples of domain behavior. Concrete examples of real scenarios help to cement processes and concepts within the domain. However, it’s important to reveal the intention of the business process and not the implementation. Talk only in business terms; don’t get technical.

在以下对话中，一位商业用户正在描述电子商务网站上的客户请求更换未送达的订单的过程：

In the following dialogue, a business user is describing the process of customers at an e-commerce site requesting a replacement for an order that wasn’t delivered:

如果顾客未收到商品，可以免费申请新的订单。她登录账户，点击“我未收到商品”按钮。如果她已被标记为已收到免费订单，则必须联系客服才能申请新的订单。否则，我们将向她发送免费订单，并更新数据库，显示该顾客已申请丢失商品。之后，我们会联系快递员，看看能否索回丢失订单的费用。

When a customer doesn’t receive her goods, she can request a new order for free. She logs into her account and clicks on the I Have Not Received My Items button. If she has already been flagged as having received a free order, she can’t get another one without speaking to customer service. Otherwise, we will send her a free order and update the database to show that this customer has already claimed for a lost item. We will then contact the courier to see if we can claim back the cost of the lost order.

您会在描述中注意到，业务用户关注的不是业务流程，而是实现问题。以下句子对领域或业务流程没有任何价值或见解：

You will notice in the description that the business user is not focusing on the business process, but rather the implementation concerns. The following sentence gives no value or insight into the domain or business process:

她登录自己的帐户并点击“我尚未收到我的物品”按钮。

She logs into her account and clicks on the I Have Not Received My Items button.

下一句中，业务用户已经开始质疑你该如何实施业务策略了。有些专家可能有数据库经验，甚至可能会建议数据模式。同样，这说明团队对该领域缺乏深入的理解：

In the next sentence, the business user is already second-guessing how you will implement the business policy. Some experts may have experience with databases and may go as far as suggesting data schemas. Again, this gives the team no deep understanding of the domain:

如果她已经被标记为收到免费订单，那么她就不能再获得另一个订单，除非与客服联系。

If she has already been flagged as having received a free order, she can’t get another one without speaking to customer service.

从这组需求来看，对领域不感兴趣的团队可能会简单地按照要求执行，最终得到一个糟糕的模型，无法反映领域的概念和策略。这可能会导致误解“标记客户”的含义；它可能不仅仅是在数据库列中打勾，甚至可能是启动单独业务工作流的催化剂。如果不了解领域和功能意图，开发人员就不会意识到仅仅按照要求执行会带来什么后果。

From this set of requirements, a team not interested in the domain may simply implement what it is told and end up with a poor model that doesn’t reflect the concepts and policies of the domain. The impact of this could be a misunderstanding of what “flagging the customer” means; it may mean more than simply a tick in a database column and perhaps the catalyst for the start of a separate business work flow. Without understanding the domain and the intent of a feature, the developers won’t appreciate the repercussions of just implementing what they are told.

教导你的领域专家专注于问题而不是急于找到解决方案

Teach Your Domain Experts to Focus on the Problem and Not Jump to a Solution

培训和协作将帮助业务人员专注于流程而非实施，专注于问题空间而非解决方案空间。接下来，之前的需求陈述已使用领域语言重写。它侧重于业务及其流程：

Training and collaboration will help business people focus on the process rather than the implementation and the problem space rather than the solution space. Next, the previous requirements statement has been rewritten using the language of the domain. It focuses on the business and its processes:

如果您尚未收到订单，可以提交未送达订单通知。如果这是您的首次索赔，则会创建替换订单。如果您之前已提出索赔，则会开立索赔案件并分配给客户服务代表，该代表将调查此索赔。在所有情况下，都会开立丢失邮件赔偿案件，并向快递员发送未送达货件的详细信息。

If you have not received an order, you can submit an undelivered order notification. If this is your first claim, a replacement order is created. If you have made a claim before, your claim case is opened and assigned to a customer service representative, who will investigate the claim. In all cases, a lost mail compensation case is opened and sent to the courier with details of the consignment that was undelivered.

在此描述中，您发现了许多之前缺失的重要领域概念。重写的文字将一些术语引入了UL，并且该领域的术语已经已经非常清晰了。事实上，第二个描述甚至不包含客户概念；相反，它只关注与流程直接相关的术语。

In this description, you have discovered many important domain concepts that were missing before. The rewritten prose introduces some terms into the UL, and the terminology of the domain has been made crystal clear. In fact, the second description doesn’t even contain the customer concept; instead, it focuses only on terms that are directly related to the process.

请记住：领域专家对技术术语缺乏理解，或者理解有限。示例应以业务为中心，如果领域专家试图通过跳到实现细节来帮助你，只需温和地提醒他们关注系统是什么以及为什么，并让他们把如何实现留给你。

Remember: domain experts have no, or limited, understanding of technical terminology. Keep examples focused on the business, and if domain experts are trying to help you by jumping to implementation details, just gently remind them to focus on the what and the why of a system and ask them to leave the how up to you.

塑造语言的最佳实践

Best Practices for Shaping the Language

以下最佳实践可帮助您塑造 UL。

The following best practices can help to shape your UL.

• 确保语言的一致性。如果您在代码中使用了领域专家没有提及的术语，则需要与其核对。您可能发现了一个必需的概念，因此需要将其添加到UL中并让领域专家理解。或者，您可能误解了领域专家的某些说法；因此，您应该使用正确的术语来纠正代码。
• Ensure that you have linguistic consistency. If you are using a term in code that the domain expert doesn’t say, you need to check it with her. It could be that you have found a concept that was required, so it needs to be added to the UL and understood by the domain expert. Alternatively, maybe you misunderstood something that the domain expert said; therefore, you should rectify the code with the correct term.
• 与领域专家一起创建领域术语词汇表，以避免混淆并帮助明确概念。
• Create a glossary of domain terms with the domain expert to avoid confusion and to help make concepts explicit.
• 确保使用一个词来表达一个特定的概念。不要让领域专家或开发人员使用两个词来表达同一个概念，因为这可能会导致混淆，或者可能存在两个具有不同上下文的概念。
• Ensure that you use one word for a specific concept. Don’t let the domain expert or developers have two words for something because this can lead to confusion, or there might be two concepts with different contexts.
• 避免使用诸如政策、服务或经理等过于繁琐的术语。即使措辞冗长，也要表达清楚。
• Stay away from overloaded terms like policy, service, or manager. Be explicit even if it means being wordy.
• 不要使用软件开发中具有特定含义的术语，例如设计模式名称，因为开发人员可能会假设它的实现而不是行为。
• Don’t use terms that have a specific meaning in software development, such as design pattern names, because developers may assume its implementation rather than behavior.
• 命名非常重要。通过与业务用户讨论类来验证你的代码设计。业务用户能理解“发送到缓存的查询，使用正则表达式匹配用户以确定他们是否获得折扣”这句话吗？当你大声朗读你的代码和概念时，它们是否有意义？如果没有意义，请咨询你的领域专家，他们会如何命名这些概念。
• Naming is very important. Validate your code design by speaking to your business users about classes. Would a business user understand “Query sent to the cache with, users matched using regex to determine if they get discount”. Does your code and concepts make sense when you say them aloud? If not ask your domain expert on how they would name concepts.
• 根据 UL 命名例外情况。
• Name exceptions in terms of the UL.
• 不要在领域模型中使用设计模式的名称。装饰器对业务用户意味着什么？他​​们会理解工厂的作用吗？也许你的业务已经有了适配器的概念；“四人帮”设计模式可能会让他们感到困惑。
• Don’t use the name of a design pattern within your domain model. What does a decorator mean to a business user? Would they understand the role of a factory? Perhaps your business already has the concept of an adapter; the Gang of Four design pattern could confuse them.
• UL 应该在任何地方都可见，从命名空间到类，从属性到方法名。使用语言来驱动代码设计。
• The UL should be visible everywhere, from namespaces to classes, and from properties to method names. Use the language to drive the design of your code.
• 随着您对所从事领域的理解不断加深，您的 UL 也会随之演变。重构代码，使用更能体现意图的方法名来适应这种演变。如果您发现一组复杂的逻辑开始形成，请与您的领域专家讨论代码的功能，看看能否为其定义一个领域概念。如果找到了，请将代码的逻辑分组拆分成一个规范或策略类。
• As you gain a deeper understanding of the domain you are working in, your UL will evolve. Refactor your code to embrace the evolution by using more intention-revealing method names. If you find a grouping of complex logic starting to form, talk through what the code is doing with your domain expert and see if you can define a domain concept for it. If you find one, separate the logical grouping of code into a specification or policy class.

不要让真相妨碍好的模型

Don’t Let the Truth Get in the Way of a Good Model

一个常见的误解是，领域模型应该贴合现实；事实上，你根本不应该试图模拟现实生活，而应该模拟问题领域内有用的抽象。寻找问题领域内的共性和差异。了解哪些可能会发生变化，哪些被认为是复杂的。利用这些信息来构建你的模型。这比基于问题领域的世界来识别名词和动词更有用。最重要的是，只建模满足业务场景需求的内容。

A common misunderstanding is that a domain model should match reality; in fact, you should not look to model real life at all but rather model useful abstractions within the problem domain. Look for commonalities and variations within the problem domain. Understand which are likely to change and are considered complex. Use this information to build your model. It will be far more useful than identifying nouns and verbs based on the world of the problem domain. Most importantly model only what is needed to meet the need of the business case scenario.

领域模型并非现实生活的模型；它是对现实的抽象系统，是一种仅包含问题领域中那些在解决特定业务用例时普遍存在的方面的解释。领域模型应该排除任何与解决问题无关的领域细节。图 4.8所示的伦敦地铁图旨在解决问题。它并不反映现实生活。它对于计算伦敦地标之间的距离没有用处，但对于乘坐地铁出行却很有用。在它被设计的语境下，它简单有效。

A domain model is not a model of real life; it is a system of abstractions on reality, an interpretation that only includes aspects of the problem domain that are prevalent to solving specific business use cases. A domain model should exclude any irrelevant details of a domain that do not serve to solve problems. The London Tube map shown in Figure 4.8 was designed to solve a problem. It doesn’t reflect real life. It isn’t useful for calculating distances between landmarks in London, but it is useful for traveling on the underground. It’s simple and effective within the context that it was designed for.

由于领域模型与实际建模无关，因此不能将其视为对错。相反，应该将其视为对其所要解决的特定问题是否有用。

Because it’s not concerned with modeling real life, the domain model cannot be deemed as being wrong or right. Rather, it should be viewed as useful or not for the given problem it is being used to solve.

创建有效的领域模型是 DDD 的基础。它是知识梳理与共享、设计洞察和突破的产物。拥有一个功能强大且富含 UL 的模型是实现问题领域业务目标的关键。创建有用的领域模型很难，需要大量的探索、实验、协作和学习。

Creating an effective domain model is fundamental to DDD. It is the artifact of knowledge crunching and sharing, design insight, and breakthroughs. Having a useful model that is rich in the UL is the key to meeting business objectives in the problem domain. Creating a useful domain model is hard and takes lots of exploration, experimentation, collaboration, and learning.

仅建模相关内容

Model Only What Is Relevant

领域模型存在的原因只有一个：服务于正在开发的应用程序。记住，创建领域模型时要有所选择；不必包含所有内容。企业规模庞大、复杂，涉及方方面面。试图在单一模型中构建这样的世界，往好了说是愚蠢的，往坏了说是极其耗时且毫无意义的。毋庸置疑，这将是一场维护的噩梦。如果您正在建模一个大型系统，请通过清晰地划分模型的各个部分，将其分解成更易于管理的块。

The domain model exists for one reason: to serve the application under development. Remember to be selective when creating your domain models; you don’t have to include everything. Businesses are big and complex with a lot going on. Trying to create that world within a single model would be at best foolish and at worst extremely time consuming and rather pointless. Needless to say, it would be a maintenance nightmare. If you are modeling a large system, break it down to more manageable chunks by clearly sectioning off parts of the model.

尽量不要对真实的关系进行建模；相反，应该根据系统中的不变量和规则来定义关联（有意义的连接）。在现实生活中，客户既有信用记录，也有联系电子邮件地址，但你有多少次会遇到这样的规则：要求你拥有良好的信用记录和以“A”开头的电子邮件地址才能购买商品？相反，应该将行为和数据分组，以满足问题领域的需求，而不是你认为可能属于同一类的情况。请记住，你创建的模型是为了满足一个业务用例（或一组业务用例）的需求，而不是试图模拟现实生活。

Try not to model real relationships; instead, define associations (meaningful connections) in terms of invariants and rules in the system. In real life, a customer has both a credit history and a contact e-mail address, but how often would you come across a rule requiring you to have a good credit history and an e-mail address starting with “A” to be able to purchase an item? Instead, group behavior and data to satisfy the needs of the problem domain rather than what you think might belong together. Remember that you are producing a model to fulfill the needs of a business use case (or set of business use cases), not trying to model real life.

为了保持领域模型的相关性和专注性，你应该不断根据新场景挑战你创建的模型，并与领域专家验证你的理解。移除任何不再相关的行为，以避免噪音。

To keep your domain model relevant and focused, you should constantly challenge the model you create against new scenarios and validate your understanding with domain experts. Remove any behavior that is no longer relevant to avoid noise.

领域模型暂时有用

Domain Models Are Temporarily Useful

领域模型需要不断完善才能持续发挥作用。领域模型只能在给定的迭代和用例集中暂时发挥作用。未来的用例或业务变更可能会导致该模型失效。领域模型代表了共享语言的实现，但仅适用于当前时刻。基于这种理解，开发人员不应过分执着于优雅的模型。如果模型变得不再适用，他们需要愿意将其抛弃并重新开始。

A domain model needs to be constantly refined to continually be useful. A domain model is only ever temporarily useful for a given iteration and set of use cases. Future use cases or changes to the business may render the model useless. The domain model represents an implementation of the shared language that is applicable for only that moment in time. It is with this understanding that developers should not be too attached to an elegant model. They need to be willing to rip up and start again if the model becomes irrelevant.

术语要明确

Be Explicit with Terminology

有效沟通是解决问题的最重要技能。开发人员的目的不是编写代码，而是解决问题。正因如此，使用一种没有歧义或无需翻译的语言与你的业务方沟通至关重要。通过消除语言障碍，领域专家和开发团队可以自由协作、探索和试验实用模型的设计。这样，技术实现就可以使用相同的通用语言 (UL) 来表达，任何设计见解都可以反馈给领域专家进行验证，而无需翻译，也不会造成语义损失。

Being able to communicate effectively is the most important skill for solving problems. A developer’s purpose is not to code; it’s to solve problems. That’s why it’s vital to talk to the business you are working for in a language without ambiguity or need of translation. By removing linguistic barriers, domain experts and the development team are free to collaborate, explore, and experiment with designs for a useful model. Technical implementations can then be expressed using the same UL, and any design insights can then be fed back to domain experts for validation without need for translation and loss of meaning.

限制你的抽象

Limit Your Abstractions

仅为了实现共通性而引入抽象，即便如此，也尽量避免使用它们。抽象是有代价的。与其担心重复，不如明确表达，因为试图将松散相关的概念绑定到超类下可能会导致代码维护问题。

Introduce abstractions for commonality only, and even then try and avoid them. Abstractions come at a cost. It is far better to be explicit than worry about not repeating yourself as trying to tie loosely related concepts under a super class can cause problems with code maintenance.

抽象类或接口应该代表领域内的一个想法或概念。限制代码库中的抽象非常重要，并且只为领域内有变体的概念创建抽象。不要试图抽象所有领域关注点。如果它不是某个概念的变体，那么就保持其具体性，并且只有在创建了它的变体时才抽象。记住，与其将重要的领域概念隐藏在层层不必要的抽象之后，不如将其明确表达。

An abstract class or an interface should represent an idea or a concept in your domain. It is really important to limit abstractions in your code base and only create them for concepts in your domain that have variations. Don’t seek to abstract every domain concern. If it’s not a variation of a concept then keep it concrete and only abstract if, and when, you create a variation of it. Remember it is always better to be explicit rather than hiding an important domain concept behind layers of needless abstraction.

那么什么时候应该抽象呢？以上班为例。抽象概念是通勤，而步行、坐火车或开车是该概念的变体；也就是具体实现。如果上班没有变体（即我们都开车），我们就不需要引入通勤这样的抽象概念。

So when should you abstract? Take the example of traveling to work. The abstract concept would be to commute whereas walking, taking the train, or driving is a variation of that concept; i.e., the concrete implementation. If there were no variation in traveling to work (i.e., we all drove) we would not need to introduce an abstract concept such as commuting.

尽早并经常在代码中实现模型

Implement the Model in Code Early and Often

至关重要的是，要根据领域场景，用代码测试你的设计，以确保你的白板思维能够发挥作用，并发现任何需要修改或妥协模型的技术限制。技术实现将揭示设计中的任何问题，并有助于巩固你对问题领域的理解。

It is vitally important to test your design in code against domain scenarios to ensure your white board thinking can work as well as discovering any technical constraints that require an alteration or compromises to the model. Technical implementations will reveal any problems with the design and will help cement your understanding of a problem domain.

不要止步于第一个好主意

Don’t Stop at the First Good Idea

只有当你的想法耗尽时才停止建模，而不是在你有了第一个好主意时就停止。一旦你有了一个有用的模型，就重新开始。挑战自己以不同的方式创建模型，试验你的思维和设计技巧。尝试用一个完全不同的模型来解决问题。如果第一次没有成功，就重构出一个更好的解决方案。不断重构你对问题领域的理解，以生成更清晰的模型。模型会随着知识的积累而改变。

Only stop modelling when you have run out of ideas and not when you get the first good idea. Once you have a useful model start again. Challenge yourself to create a model in a different way, experiment with your thinking and design skills. Try to solve the problem with a completely different model. If you don’t get it right the first time, refactor to a better solution. Constantly refactor to your understanding of the problem domain to produce a more express model. Models will change with more knowledge.

记住，模型只是暂时有用的；不要执着于华丽的设计。抛弃模型中不再有用的部分，并准备好在新的用例和场景出现时进行修改。

Remember a model is only useful for a moment in time; don’t get attached to elegant designs. Rip up parts of your model that are no longer useful, and be willing to change when new use cases and scenarios are thrown at your design.

如果不值得付出努力，就不要尝试模仿

If It’s Not Worth the Effort Don’t Try and Model It

如果你遇到一个特别棘手且复杂的边缘情况，并且它位于系统非核心区域，那么你应该考虑将其变为手动流程。与其处理边缘情况，不如将其明确地变为手动流程，这样可以节省宝贵的时间，让你能够更好地资源用于核心领域的工作。人类和手动流程擅长处理边缘情况，并且通常可以根据需要大量时间复制的数据做出决策。

If you have a particularly nasty and complex edge case that is in an area of the system that is not core then you should think about making it a manual process. Not handling edge cases and making them an explicit manual process instead can save valuable time and give you more resources to work on the core domain. Humans and manual processes are great at edge cases and can often make decisions based on data that would take a considerable amount of time to replicate.

专注于核心领域

Focus on the Core Domain

应用程序的核心领域决定了它被构建而非购买的原因。它是利益相关者最热衷的领域，也是你们可以进行有趣的对话和宝贵的知识交流的地方。这是你的UL能为你带来最大价值，也需要你专注的领域。尽量不要为整个领域创建丰富的语言，因为许多支持领域和通用领域不需要，而且只会浪费精力。将精力集中在能带来价值的领域上。尽量不要为所有领域都创建UL。不复杂的领域和子领域不会从UL中受益，所以不要分散精力。核心领域很小；专注于它。创建UL的成本很高。

The core domain of your application is why it is being built rather than bought. It is what your stakeholders are most passionate about, and where you can have interesting conversations and valuable knowledge-crunching sessions. This is the area where your UL gives you the most value, and demands your focus. Try not to create a rich language for your entire domain because many of your supporting and generic domains do not require one and are a waste of effort. Focus your efforts on what gives you value. Try not to create a UL for everything. Areas and subdomains that are not complex will not benefit from a UL, so don’t spread yourself too thin. A core domain is small; focus on it. Creating a UL is costly.

领域模型

Domain Model

Martin Fowler 在其《企业应用架构模式》一书中介绍了领域模型模式，该模式与 DDD 同义，因为它非常适合处理具有丰富业务逻辑的复杂领域。领域模型是一个面向对象的模型，它融合了行为和数据。乍一看，它可能与数据持久化模型（如果您使用的是关系数据库，则为数据模式）相似。虽然两者都包含数据，但领域模型还融合了业务流程和关联、规则以及丰富的领域逻辑。DDD 提供了许多构建块模式（将在第三部分中介绍），这些模式将帮助您更有效地实现 Fowler 的领域模型模式。

The domain model pattern, catalogued in Martin Fowler’s Patterns of Enterprise Application Architecture, is synonymous with DDD because it is a good fit for complex domains with rich business logic. The domain model is an object-oriented model that incorporates both behavior and data. At first glance, it may mirror the data persistence model (data schema if you are using a relational database). Although both contain data, the domain model also incorporates business process and associations, rules, and rich domain logic. DDD offers a number of building block patterns, which are covered in Part III, which will enable you to implement Fowler’s domain model pattern more effectively.

领域模型模式基于无数据库的前提；因此，它可以以完全忽略持久性的方式演进和创建。在设计模型时，您无需从数据模型入手，而是从代码模型入手——这是模型驱动的设计，而非数据驱动的设计。只有当您必须考虑模型的持久化时，才可以在设计上做出妥协。模型中的领域对象被称为普通旧式 C# 对象 (POCO)。这些类无需考虑基础设施，并且完全忽略持久性。图 5.3展示了领域模型模式与技术基础设施是如何分离的。

The domain model pattern is based on the premise that there is no database; therefore, it can evolve and be created in a completely persistence-ignorant manner. When designing the model, you don’t start with a data model; instead, you start with the code model—model-driven as opposed to data-driven design. Only when you have to think about persisting the model can you compromise on the design. Domain objects within the model are known as Plain Old C# Objects (POCO). These classes are free from infrastructure concerns and are completely persistence ignorant. Figure 5.3 shows how the domain model pattern and technical infrastructure are kept separated.

这种只关注领域模型的能力使得领域逻辑的设计能够由领域抽象驱动——这就是 DDD。通过不考虑持久化需求，您可以构建一个纯粹专注于当前领域问题的富有表现力的模型。当然，您需要对其进行持久化，并且可能需要做出妥协，但在建模时您不应该考虑这些。这使得领域模型摆脱了基础架构代码的束缚，而只专注于领域逻辑。

This ability to focus only on the domain model enables the design of the domain logic to be driven by the abstractions of the domain—hence, DDD. By not thinking about persistence needs, you can build an expressive model purely focused on the domain problem at hand. Of course you will need to persist it and may need to compromise, but you should not think about this when modelling. This keeps the domain model free of infrastructural code and focused only on domain logic.

您可以将领域模型视为一个概念层，它代表您正在处理的领域。事物存在于此模型中，并与其他事物之间存在关联。例如，如果您正在构建一个电子商务商店，那么存在于模型中的“事物”将代表购物篮、订单、订单项等等。这些事物不仅拥有数据，更重要的是，它们拥有行为。订单不仅拥有代表创建日期、状态和订单号的属性，还包含应用折扣券的业务逻辑，以及围绕它的所有领域规则：优惠券是否有效？优惠券可以与购物篮中的产品一起使用吗？是否存在其他会导致优惠券无效的优惠？

You can think of a domain model as a conceptual layer that represents the domain you are working in. Things exist in this model and have relationships to other things. For example, if you were building an e-commerce store, the “things” that would live in the model would represent a Basket, Order, Order Item, and the like. These things have data and, more importantly, they have behavior. Not only would an order have properties that represent a creation date, status, and order number, but it would contain the business logic to apply a discount coupon, including all the domain rules that surround it: Is the coupon valid? Can the coupon be used with the products in the basket? Are there any other offers in place that would render the coupon invalid?

图 5.4展示了一个在线拍卖网站的部分领域模型。模型中的对象代表了问题领域的概念，用于实现拍卖的行为。正如你所见，该模型与拍卖领域的名词相对应，但情况并非总是如此。事实上，在建模时，你应该关注问题领域的动词和动作，因为这将帮助你专注于行为而不是状态，最终帮助你创建面向对象的数据模型表示。

Figure 5.4 shows part of the domain model for an online auction site. The objects in the model represent concepts of the problem domain that are used to fulfill the behaviors of an auction. As you can see, the model aligns with the nouns of the auction domain but this is not always the case. In fact you should focus on the verbs and actions of a problem domain when modeling as this will help you concentrate on behavior rather than state, which could end up with your creating an object-oriented representation of the data model.

在领域模型中，每个对象负责一项特定的任务。对象之间通过相互委托来协同工作，完成业务用例。在清单 5-1 中，您可以看到 Auction 类如何委托 WinningBid 来确定下一个出价增量。

In a domain model each object is responsible for a specific task. Objects work together to fulfill business use cases by delegating to each other. In Listing 5-1 you can see how the Auction class delegates to a WinningBid to determine the next price of the bid increment.

当您需要建模一个复杂、丰富且复杂的业务领域时，领域模型会非常有效。它是一种纯粹的面向对象方法，涉及创建真实业务领域的抽象模型，在处理复杂的逻辑和工作流时非常有用。领域模型不依赖持久层，依赖于映射器类和其他抽象模式来持久化和检索业务实体。如果您需要建模复杂的逻辑或问题域中某个部分，而该部分非常重要，需要清晰的表达，或者由于持续投入而经常发生变化，那么领域模型模式是一个不错的选择。

The domain model excels when you have an involved, rich, complex business domain to model. It’s a pure object-oriented approach that involves creating an abstract model of the real business domain and is useful when dealing with complex logic and workflow. The domain model is persistence ignorant and relies on mapper classes and other abstraction patterns to persist and retrieve business entities. If you have to model complex logic or part of the problem domain that requires clarity because it’s important, or will change often due to continued investment, it’s a good candidate for the domain model pattern.

领域模型模式并非灵丹妙药，因为实现成本可能很高。它在技术上最具挑战性，需要开发人员精通面向对象编程。大多数子系统都是基于 CRUD 的，只有核心领域才需要领域模型实现模式来确保清晰度或管理复杂的逻辑。你不应该尝试将领域模型模式应用于所有内容。应用程序的某些部分可能只是基于数据的表单，只需要基本验证，而无需丰富的业务逻辑。试图对所有事物进行建模并应用面向对象实践只会浪费精力，这些精力最好花在你的核心领域上。软件开发就是为了让事情变得更简单，所以如果你有复杂的逻辑，请应用领域模型模式；否则，寻找适合你所遇到问题的模式，例如贫血领域模型或表模块模式。

The domain model pattern is no silver bullet as it can be costly to implement. It’s the most technically challenging and requires developers with a good grasp of object-oriented programming. The majority of sub systems are CRUD based, with only the core domain requiring the domain model implementation pattern to ensure clarity or to manage complex logic. What you should not do is try to apply the domain model pattern for everything. Some parts of your application will simply be forms over data and will require just basic validation instead of rich business logic. Trying to model everything and apply object-oriented practices would be a waste of effort that would be better spent on your core domain. Software development is all about making things simpler, so if you have complex logic, apply the domain model pattern; otherwise, look for a pattern that fits the problem you have, like the anemic domain model or the table module pattern.

如果你正在开发的应用程序部分没有频繁变化的逻辑，而只是一种数据形式，那么最好不要尝试应用领域模型模式。最多也就是错误地使用领域模型模式可能会导致精力的浪费；最糟糕的是，你会引入不必要的复杂性，而使用更简单的实现方法就足够了。

If the portion of the application you are working on does not have frequently changing logic and is merely a form of data, it is best not to try to apply the domain model pattern. At best, incorrectly using the domain model pattern can lead to a waste of effort; at worst, you introduce needless complexity where a simpler implementation method would have sufficed.

交易脚本

Transaction Script

在本章中你将了解的所有领域逻辑模式中，事务脚本是迄今为止最容易理解和上手的。事务脚本模式遵循过程式开发风格，而非面向对象方法。通常，每个业务事务都会创建一个单独的过程，并将其分组到某种静态管理器或服务类中。每个过程都包含完成业务事务所需的所有业务逻辑，包括工作流、业务规则、验证检查以及数据库持久化。

Of all the domain logic patterns you will read about in this chapter, transaction script is by far the easiest to understand and get up and running with. The transaction script pattern follows a procedural style of development rather than an object-oriented approach. Typically a single procedure is created for each of your business transactions, and it is grouped in some kind of static manager or service class. Each procedure contains all the business logic that is required to complete the business transaction from the workflow, business rules, and validation checks to persistence in the database.

图 5.5显示了事务脚本模式的图形表示。

Figure 5.5 shows a graphical representation of the transaction script pattern.

图 5.6展示了实现事务脚本模式的接口示例签名。这两个实现分别包含了处理创建拍卖和竞价业务所需的所有逻辑，包括数据访问和持久化逻辑、授权、事务并发性和一致性问题。

Figure 5.6 shows the example signature of an interface that is implementing the transaction script pattern. The two implementations contain all of the logic they require to handle the business cases of creating an auction and bidding on an auction, respectively, including data access and persistence logic, authorization, transactional concurrency, and consistency concerns.

事务脚本模式的优势之一是它易于理解，即使新团队成员不具备该模式的先验知识，也能快速上手。随着新需求的出现，可以轻松地向类中添加更多方法，而不必担心影响或破坏现有功能。

One of the strengths of the transaction script pattern is that it’s simple to understand and can be fast to get new team members up to speed without prior knowledge of the pattern. As new requirements arise, it is easy to add more methods to the class without fear of impacting or breaking existing functionality.

继续讨论在线拍卖领域，请考虑清单 5-2。交易脚本代表了拍卖竞价的用例。

Continuing with the online auction domain, consider Listing 5-2. The transaction script represents the use case of bidding on an auction.

如您所见，整个业务用例都封装在一个方法中。该类负责处理许多任务，例如数据检索和持久化、事务管理以及完成投标所需的业务逻辑。

As you can see, the entire business case is encapsulated within a single method. The class is dealing with many responsibilities such as data retrieval and persistence, transaction management, as well business logic to fulfill the place of a bid.

事务脚本是一种简单的过程模式，适用于领域中逻辑很少或没有逻辑的部分。操作的所有逻辑都包含在一个服务方法中。任何开发人员都能快速掌握用于建模领域逻辑的架构。因此，对于由不熟悉面向对象编程概念的初级开发人员组成的团队来说，这是一种非常有用的模式。但是，如果逻辑变得复杂，事务脚本模式很快就会变得难以管理，因为其本质上很容易出现重复。如果出现过多的重复，请根据领域模型模式重构代码。

Transaction script is a simple procedural pattern that is useful for the parts of your domain that have little or no logic. All logic for an operation is contained within a single service method. Any developer can quickly come to grips with the architecture used to model domain logic. Therefore it is a helpful pattern for teams with junior developers who are not comfortable with object-oriented programming concepts. However, if logic becomes complex, the transaction script pattern can quickly become hard to manage because, by its nature, duplication can occur quickly. If excessive duplication occurs, refactor the code toward the domain model pattern.

当应用程序规模扩大、业务逻辑复杂度增加时，事务脚本模式的问题就暴露无遗。随着应用程序的扩展，方法的数量也会随之增加，导致 API 中充斥着功能重叠且细粒度的方法，从而变得毫无用处。您可以使用子方法来避免重复的代码（例如验证和业务规则），但工作流中的重复是不可避免的，并且随着应用程序的增长，代码库很快就会变得笨重且难以管理。

The problems with the transaction script pattern are revealed when an application grows and the business logic complexities increase. As an application is extended, so is the mass of methods, making for an unhelpful API full of fine-grained methods that overlap in terms of functionality. You can use sub methods to avoid repetitive code such as the validation and business rules, but duplication in the workflow cannot be avoided, and the code base can quickly become unwieldy and unmanageable as the application grows.

表格模块

Table Module

表模块模式将对象模型映射到数据库模型。单个对象代表数据库中的一个表或视图。该对象负责所有持久化需求以及业务逻辑行为。此模式的优点是对象模型和数据库模型之间没有不匹配的情况。表模块模式非常适合数据库驱动设计，因此乍一看它可能不太适合 DDD。但是，对于领域中由有界上下文隔离且仅仅是数据形式化的简单部分，此模式非常适合，并且比领域模型模式更容易掌握。但是，如果对象模型和数据库模型开始出现分歧，则需要重构到领域模型模式。

The table module pattern maps the object model to the database model. A single object represents a table or view in the database. The object is responsible for all persistence needs along with business logic behavior. The benefit of this pattern is that there is no mismatch between the object model and the database model. The table module pattern is a great fit for Database-Driven Design, so on first glance it might not be a good fit for DDD. However, for simpler parts of the domain that are isolated by a bounded context and that are simply forms over data, this pattern is a good fit and easier to come to grips with than the domain model pattern. If, however, the object model and database model start to diverge, you need to refactor toward the domain model pattern.

活动记录

Active Record

活动记录是表模块模式的一种变体，它将对象映射到表的行，而不是用对象本身来表示表。对象表示处于临时状态或正在修改的数据库行（记录）。

Active record is a variation of the table module pattern that maps objects to rows of a table as opposed to having objects represent the tables themselves. An object represents a database row (record) in a transient state or under modification.

活动记录模式是一种流行的模式，当你的底层数据库模型与你的业务模型相匹配时，它尤其有效。通常，数据库中的每个表都有一个业务对象。业务对象代表该表中的一行，包含数据和行为、持久化数据的方法、添加新实例和查找对象集合的方法。

The active record pattern is a popular pattern that is especially effective when your underlying database model matches your business model. Typically, a business object exists for each table in your database. The business object represents a single row in that table and contains data and behavior, as well as a means to persist it, and methods to add new instances and find collections of objects.

在活动记录模式中，每个业务对象负责自己的持久性和相关的业务逻辑。

In the active record pattern, each business object is responsible for its own persistence and related business logic.

活动记录模式非常适合数据模型与业务模型之间具有一对一映射的简单应用程序，例如博客或论坛引擎；如果您已有数据库模型或倾向于以“数据优先”的方式构建应用程序，那么它也是一个很好的选择。由于业务对象与数据库中的表具有一对一映射，并且都具有相同的创建、读取、更新和删除 (CRUD) 方法，因此可以使用代码生成工具自动生成业务模型。优秀的代码生成工具还会内置所有数据库验证逻辑，以确保只允许有效数据进行持久化。

The active record pattern is great for simple applications that have one-to-one mapping between the data model and the business model, such as with a blogging or a forum engine; it’s also a good pattern to use if you have an existing database model or tend to build applications with a “data first” approach. Because the business objects have a one-to-one mapping to the tables in the database and all have the same create, read, update, and delete (CRUD) methods, it’s possible to use code generation tools to auto-generate your business model for you. Good code generation tools also build in all the database validation logic to ensure that you are allowing only valid data to be persisted.

贫血领域模型

Anemic Domain Model

贫血领域模型有时被称为反模式。乍一看，该模式与领域模型非常相似，因为您仍然会找到代表业务领域的领域对象。然而，任何行为都不包含在领域对象中。相反，它位于模型之外，领域对象只是简单的数据传输类。该模式的主要缺点是，领域服务承担了一种更具过程性的代码风格，类似于您在本章开头看到的事务脚本模式，这带来了与之相关的问题。其中一个问题就是违反了“告诉，不要询问”原则，该原则规定对象应该告知客户端它们能做什么、不能做什么，而不是暴露属性，让客户端自行判断对象是否处于特定状态以执行特定操作。领域对象被剥离了逻辑，仅仅是数据容器。

The anemic domain model is sometimes referred to as an anti-pattern. At first glance, the pattern is very similar to the domain model in that you will still find domain objects that represent the business domain. Any behavior, however, is not contained within the domain objects. Instead, it is found outside of the model, leaving domain objects as simple data transfer classes. The major disadvantage of this pattern is that the domain services take on the role of a more procedural style of code rather like the transaction script pattern that you saw at the beginning of the chapter, which brings along the issues associated with it. One such issue is the violation of the “Tell, Don’t Ask” principle, which states that objects should tell the client what they can or can’t do rather than exposing properties and leaving it up to the client to determine if an object is in a particular state for a given action to take place. Domain objects are stripped of their logic and are simply data containers.

对于逻辑较少的领域模型部分，或者不太熟悉面向对象编程技术的团队，贫血领域模型模式是一个不错的选择。贫血领域模型可以整合 UL，是尝试创建丰富领域模型的良好开端。

The anemic domain model pattern is a good candidate for parts of your domain model that have little logic or for teams not very experienced with object-oriented programming techniques. The anemic domain model can incorporate the UL and be a good first step when trying to create a rich domain model.

贫血领域模型和函数式编程

Anemic Domain Model and Functional Programming

领域驱动设计完全适用于那些偏爱函数式编程而非面向对象编程的开发者。领域模型可以轻松使用函数式概念（例如不变性和引用透明性）构建。行为丰富的对象并非必需，将状态隔离在行为接口之后也并非必需。因此，贫血领域模型模式实际上是函数式编程中一个非常有用的概念，而不是一种反模式。

Domain-Driven Design is fully accessible to developers who prefer functional to object-oriented programming. Domain models can easily be built using functional concepts like immutability and referential transparency. Behavior-rich objects are not a necessity, nor is isolating state behind behavioral interfaces. Accordingly, the anemic domain model pattern is actually a fundamentally useful concept when using functional programming as opposed to being an anti-pattern.

领域模型的存在是为了方便与领域专家进行对话，而贫血领域模型模式却阻碍了将领域概念表示为对象，这看似矛盾。然而，正如许多现代 DDD 从业者所言，最重要的领域概念是动词——不是像银行账户这样的名词，而是像转账这样的动词。借助函数式编程和贫血领域模型，您仍然可以充分表达领域动词，从而与领域专家进行有意义的对话。

It may seem contradictory that domain models are there to facilitate conversations with domain experts, and yet the anemic domain model pattern precludes the ability to represent domain concepts as objects. However, as many modern DDD practitioners assert, the most important domain concepts are verbs—not the nouns like a bank account, but the verbs like transferring funds. With functional programming and the anemic domain model, you still have the power to fully express domain verbs, and consequently to have meaningful conversations with domain experts.

在构建功能性领域模型时，即使使用贫血领域模型模式，仍然可以拥有表示领域概念的结构。但值得注意的是，它们只是没有行为的数据结构——因此是一个行为丰富、面向对象的BankAccount实体，如清单 5-3 所示。

When building functional domain models, it is still possible to have structures that represent domain concepts, even when using the anemic domain model pattern. Significantly, though, they are just data structures with no behavior—so a behavior-rich, object-oriented BankAccount entity, as shown in Listing 5-3.

将被建模为一个纯粹的、不可变的日期结构，如清单 5-4 所示：

Would be modeled as a pure, immutable date structure, as in Listing 5-4:

将对象简化为纯数据结构后，行为将以纯函数的形式存在，而挑战在于如何根据概念领域模型将它们紧密地分组和组合。一个有效的方法是将函数分组为聚合。函数的另一个重大区别在于它们的结构和职责。由于函数式编程要求不变性，因此函数需要返回更新的数据结构，而不是改变现有对象的状态。例如，面向对象的ShoppingBasket可以在客户每次添加产品时直接更新其Items集合，如清单 5-5 所示。

Having reduced objects into pure data structures, behavior then exists as pure functions, and the challenge is to cohesively group and combine them aligned with the conceptual domain model. One effective option is to group functions into aggregates. The other big divergence with your functions is their structure and responsibility. Since functional programming necessitates immutability, your functions need to return updated data structures rather than mutating the state of existing objects. For example, an object-oriented ShoppingBasket may directly update its Items collection each time the customer adds a product, as seen in Listing 5-5.

采用功能方法，不是更新Items集合，而是返回ShoppingBasket的副本，其中包含更新的、不可变的Items集合，如清单 5-6 所示。

Taking the functional approach, instead of updating the Items collection, a copy of the ShoppingBasket is returned that contains an updated, immutable Items collection, as seen in Listing 5-6.

请注意，Items集合不再能够被封装，因为函数无法访问ShoppingBasket的私有状态。

Notice the Items collection can no longer be encapsulated since functions cannot access the ShoppingBasket’s private state.

一些编程语言，包括 Haskell、Scala 和 Clojure，将函数式编程作为首要特性。但在传统的面向对象语言（如 C# 和 Java）中，仍然可以构建函数式领域模型。

Some programming languages, including Haskell, Scala, and Clojure, make functional programming a first-class feature. But it is still possible to build functional domain models in traditionally object-oriented languages like C# and Java.

模型的复杂性可以增长

A Model Can Grow in Complexity

大型模型涵盖众多领域概念，并执行众多业务用例。因此，很容易犯错，并将错误的概念归为一类。此外，找到所需内容也会非常困难。系统规模越大，这些问题就越严重，从而减慢了添加新功能和改进的速度。

Large models accommodate many domain concepts and carry out many business use cases. As a consequence, it is easy to make mistakes and group the wrong concepts together. It can also be very difficult to find what you are looking for. The more the system grows, the more severe these problems become, slowing down the speed at which new features and improvements can be added.

如图6.1所示，随着每个新用例和见解纳入模型，模型中的概念和依赖关系的数量会增加，从而导致复杂性增加。

As Figure 6.1 highlights, with each new use case and insight incorporated into the model, the number of concepts and dependencies in the model grows, resulting in increased complexity.

多个团队共同开发一个模型

Multiple Teams Working on a Single Model

代码复杂只是单一模型带来的问题之一。协作开销和组织效率低下也是单片模型可能引发的主要问题。

Complex code is just one of the problems arising from a single model. Collaboration overhead and organizational inefficiencies are also major problems a monolithic model is likely to cause.

当一个团队想要发布新功能时，他们必须与其他团队确认他们的更改是否也能部署。第一个团队要么必须等待，要么必须使用复杂的分支策略。正如第 11 章“有界上下文集成简介”更详细地解释的那样，复杂的分支策略可能会严重阻碍组织频繁高效地交付业务价值并了解客户的能力。

As one team wants to release a new feature, they have to check with other teams that their changes can also be deployed. Either the first team will have to wait, or complex branching strategies will be used. As Chapter 11, “Introduction to Bounded Context Integration,” explains in more detail, complex branching strategies can be a big hindrance to an organization’s ability to frequently and efficiently deliver business value and learn about their customers.

不断要求团队协作设计新功能或计划发布版本是不必要的低效行为。由于每个团队都与各自的领域专家合作，并试图将模型推向不同的方向，因此拖累其他团队会造成相互浪费。团队越多，协作成本就越高，代码库也就越复杂，如图6.2所示。

Continually requiring teams to collaborate on the design of new features or to plan releases is an unnecessary inefficiency. As each team works with their own domain expert and tries to drive their model in different directions, dragging other teams along with them is mutually wasteful. The more teams, the more expensive the collaboration overhead, and the more complex the codebase, as Figure 6.2 illustrates.

如果使用多个模型，团队可以迭代他们的模型并频繁有效地提供新价值，因为他们不必与其他团队同步或关注其他团队模型中的概念。

If multiple models are used instead, teams can iterate on their models and deliver new value frequently and efficiently because they do not have to synchronize with other teams or concern themselves with concepts from other teams’ models.

您可能会担心团队在每个模型中重复代码。但请关注消除团队间依赖关系所带来的好处。本质上，模型间重复代码是可以的，因为概念并不相同。

You may be concerned about a team’s duplicating code in each of their models. But focus on the benefits that arise by removing dependencies between teams. Essentially, it is Ok to duplicate code between models because the concepts are not the same.

模型语言的歧义

Ambiguity in the Language of the Model

DDD 从业者的一个顿悟是，他们意识到系统中的一些概念非常相似——它们甚至可能同名。然而实际上，它们对业务的不同部门而言含义截然不同。如图6.3所示，“工单”概念对销售部门和客服部门而言含义不同。

One of the epiphanies that DDD practitioners have is the realization that some concepts in a system are very similar—they might even have the same name. Yet actually, they mean very different things to different parts of the business. As Figure 6.3 illustrates, the “Ticket” concept means different things to the Sales and Customer Service departments.

一旦你接受了名称在不同语境下可能具有不同含义这一事实，你就更容易接受多个小型模型比单个大型模型更有效。你也能与领域专家进行更有意义的讨论。例如，根据图 6.3，当你与销售经理讨论门票时，你知道她关心的是活动的费用和地点；而与客服经理讨论门票时，则会关注客户提出的问题的严重性和类别。

Once you accept that names can have different meanings in different contexts, it’s easier to accept that multiple smaller models are more effective than a single large one. You can also have more meaningful discussions with domain experts. For example, based on Figure 6.3, when talking to the Sales manager about tickets, you know she cares about the cost and location of an event; whereas discussion about tickets with the Customer Service manager will be focused on the severity and category of problems raised by customers.

领域概念的适用性

The Applicability of a Domain Concept

有时，问题域中的单个物理实体可能会被错误地归类为代码中的单个概念。当物理实体实际上代表多个概念，并且每个概念在不同上下文中具有不同含义时，这种情况就会很麻烦。典型的例子就是产品。

Sometimes, a single physical entity in the problem domain can mistakenly be classified as a single concept in code. This is problematic when the physical entity actually represents multiple concepts, that each mean different things in different contexts. The classic example is a product.

图 6.4展示了产品在不同情境下的含义。对于采购团队来说，产品是一个必须以盈利利润和可接受的交付周期才能获得的概念。然而，对于销售团队来说，产品只是一个包含图片、尺码指南并属于某个销售类别的概念——这些都与采购团队无关，尽管在问题领域中，它们实际上是同一个物理实体。

Figure 6.4 shows how products mean different things in different contexts. It is a concept that must be acquired with a profitable margin and acceptable lead time to the Procurement team. Yet to the Sales team a product is a concept with images, size guides, and belongs to a selling category—none of which are relevant to the Procurement team, even though it is the same physical entity in the problem domain.

当一个物理实体（例如产品）实际上代表多个领域概念时，开发人员通常会将其建模为单个概念。不幸的是，我们很容易陷入这样的思维陷阱：因为产品可以是物理实体，所以在代码中也应该将其建模为单个类。这会导致耦合，因为每个模型都共享同一个产品类，如图6.5所示。

When a physical entity, such as a product, actually represents multiple domain concepts, it is often modeled as a single concept by developers. Unfortunately, it’s very easy to fall into the trap of thinking that because a product can be a physical item that it should be modeled as a single class in code. This leads to coupling, as each model shares the same product class, as shown in Figure 6.5.

如前所述，当多个上下文耦合时，代码可能会变得过于复杂，团队之间的协作成本也会变得非常高昂。在这个示例产品中，共享类也违反了单一职责原则 (SRP)，因为四个上下文都出于完全不同的原因而希望它进行更改。

As discussed previously, when multiple contexts are coupled, code can become excessively complex and the collaboration overhead between teams can become excessively costly. The shared class, in this example product, also violates the Single Responsibility Principle (SRP), since there are four contexts that all want it to change for completely different reasons.

当代码中没有边界时，很容易产生耦合，就像图 6.5所示的产品一样。一个更好的降低耦合的解决方案是为每个上下文（促销、分配、忠诚度和运输）设置各自的模型。这样，每个模型都将包含一个唯一的产品表示，该表示仅满足模型上下文的需求。图 6.6展示了共享Product类的多项职责，并指明了它们各自应该属于哪个模型。

When there are no boundaries in the code, it is too easy for coupling to occur, as with the product shown in Figure 6.5. A better solution that reduces the coupling would be for each context—Promotion, Allocation, Loyalty, and Shipping—to have its own model. Each model would then contain a unique representation of a product that only satisfies the needs of the model’s context. Figure 6.6 shows the multiple responsibilities of the shared Product class, indicating which model each of them should really belong in.

与遗留代码或第三方代码集成

Integration with Legacy Code or Third Party Code

选择较小模型的另一个原因是，与遗留代码或第三方集成的问题更少。当有大量遗留代码时，向单体代码库添加新功能可能会非常痛苦。您希望添加与领域专家共同创建的简洁、全新且富有洞察力的模型，但遗留代码的局限性可能会限制设计的表达能力。但是，如果您拥有较小的模型，则并非所有模型都需要接触遗留代码。

Another reason to prefer smaller models is that integrating with legacy code or third parties can be less problematic. Adding new features to a monolithic codebase can be painful when there is lots of legacy code. You want to add clean, new, insightful models that you created with domain experts, but the limitations of legacy code can constrain the expressiveness of your design. But if you have smaller models, not all of them will need to touch the legacy code.

第 11 章讨论的许多模式展示了当您有多个较小的模型可供使用时如何更轻松地将 DDD 应用于遗留系统。

A number of patterns, discussed in Chapter 11, show how it is easier to apply DDD to legacy systems when you have multiple smaller models to work with.

您的域模型不是您的企业模型

Your Domain Model Is not Your Enterprise Model

在某些情况下，拥有一个涵盖整个系统的单一模型很有用，包括业务信息 (BI) 和报告。然而，企业模型并非创建可演进、能够明确表达领域概念的领域模型的最佳解决方案。企业模型也不适合旨在频繁交付业务价值的迭代开发流程。

Having a single model of the entire system is useful in some scenarios, including business information (BI) and reporting. However, the enterprise model is not the best solution for creating an evolvable domain model that explicitly expresses domain concepts. Nor is an enterprise model suitable for iterative development processes that aim to deliver business value frequently.

图 6.7展示了如何兼顾两方面的优势——针对每种情况的独特模型和针对 BI 的企业模型。

Figure 6.7 shows how you can have the best of both worlds—a unique model for each context and an enterprise model for BI.

定义模型的边界

Defining a Model’s Boundary

在大型系统中，有界上下文的必要性显而易见，但识别有界上下文及其边界的过程却充满挑战。幸运的是，这并不是一个必须事先做出完全正确的决定。随着您对领域了解的加深，您可以调整有界上下文的边界。

The need for bounded contexts is clear in larger systems, but the process of identifying bounded contexts and their boundaries is challenging. Fortunately, it’s not an up-front decision you have to get perfectly correct. As you learn more about the domain, you can adjust the boundaries of your bounded contexts.

问题域的两个方面可以作为识别有界上下文的指南——术语和业务能力。正如您在本章前面所看到的，同一个术语在不同的上下文中可能具有不同的语义。如果您可以根据单词或短语含义的变化来描绘领域模型，那么您很可能已经确定了有界上下文的边界。业务能力通常很容易辨别，但也可能具有误导性。例如，如果一个企业有一个销售部门和一个客户服务部门，那么很可能存在销售和客户有界上下文。但这并非总是如此，因此重要的是不要盲目地对业务能力进行建模。

There are two aspects of a problem domain that you can use as a guide to identifying bounded contexts—terminology and business capabilities. As you’ve seen previously in this chapter, the same term can have different semantics in different contexts. If you can delineate a domain model based on a change in the meaning of a word or phrase, you will very likely have identified the boundary of a bounded context. Business capabilities are often easy to discern but can be misleading. For example, if a business has a Sales department and a Customer Service department, there is very likely to be a sales and customer bounded context. But that’s not always true, so it’s important not to blindly model business capabilities.

在问题领域之外，团队结构和位置也会对上下文边界产生很大影响，与遗留系统或第三方系统的集成也会对上下文边界产生很大影响。

Outside of the problem domain, team structure and location can also be a big influence on context boundaries, as can integrating with legacy or third-party systems.

然而，大小并非界定有界上下文的准则。没有绝对或相对的值可以告诉你需要多少个类或多少行代码。有界上下文的大小主要取决于问题域的各个方面。因此，有些有界上下文可能很大，而有些则很小。

Size, though, is not a guideline for delineating bounded contexts. No absolute or relative value can tell you how many classes or lines of code you need. A bounded context’s size is dependent mostly on aspects of the problem domain. Some bounded contexts may, therefore, be large while others are small.

总而言之，上下文边界可能受到以下因素的影响：

To summarize, context boundaries can be influenced by the following:

• 领域术语和概念的歧义
• Ambiguity in terminology and concepts of the domain
• 与子域和业务能力保持一致
• Alignment to subdomains and business capabilities
• 团队组织和实际位置
• Team organization and physical location
• 遗留代码库
• Legacy code base
• 第三方集成
• Third party integration

子域和有界上下文之间的区别

The Difference between a Subdomain and a Bounded Context

子域，如第三章“聚焦核心域”所述，代表问题域的逻辑区域，通常反映业务组织结构的业务能力。它们用于区分应用程序中的重要区域（核心域）和不太重要的区域（支持域和通用域）。子域的存在是为了提炼问题空间并分解复杂性。

Subdomains, introduced in Chapter 3, “Focusing on the Core Domain,” represent the logical areas of a problem domain, typically reflecting the business capabilities of the business organizational structure. They are used to distinguish the areas of importance in an application, the core domain, from the less important areas, the supporting and generic domains. Subdomains exist to distill the problem space and break down complexity.

领域模型的构建是为了满足每个子领域的用例。理想情况下，模型和子领域之间应该存在一对一的映射，但情况并非总是如此。模型的定义基于团队结构、语言的歧义性、业务流程的一致性或物理部署。因此，一个子领域可能包含多个模型，而一个模型也可能跨越多个子领域。在传统环境中，这种情况很常见。

Domain models are built to fulfill the uses cases of each of the subdomains. Ideally there would be a one-to-one mapping between models and subdomains, but this is not always the case. Models are defined based on team structure, ambiguity in language, business process alignment, or physical deployment. Therefore a subdomain could contain more than a single model and a model could span more than a single subdomain. This is often the case within legacy environments.

为了保持纯粹性和专注性，模型需要被隔离并定义在一个明确的上下文中。正如你所了解的，这个上下文被称为有界上下文。与子域不同，有界上下文是一种具体的技术实现，它强制规定应用程序内模型之间的边界。有界上下文存在于解决方案空间中，并在上下文中表示为显式的领域模型。

Models need to be isolated and defined within an explicit context in order to stay pure and focused. As you’ve learned, this context is known as the bounded context. Unlike a subdomain, a bounded context is a concrete technical implementation that enforces boundaries between models within an application. Bounded contexts exist in the solution space and are represented as explicit domain models in a context.

技术现实

The Technical Reality

如图 7.2所示，该图的技术细节展示了上下文之间的集成点。这张热力图对于团队理解其变更的技术含义至关重要。它显示了现有的边界以及用于维护有界上下文完整性的任何转换。

The technical details of the map, as shown in Figure 7.2 demonstrate the integration points between contexts. This heat map is vital for teams to understand the technical implications of their changes. It shows the boundaries that exist and any translations that are used to retain the integrity of bounded contexts.

极其重要的是，上下文图要反映现实，展示代码的当前状态，而不是理想的未来状态。上下文图不必展示模型的细节；相反，它们必须展示有界上下文之间的集成点和数据流。与代码模型和分析模型一样，上下文图应该只在代码发生变化时才进行调整，这样才不会给人留下错误的印象。上下文图应该展现真实的现实；只有这样，它才有用。

It is extremely important that context maps reflect reality, showing the code in the present state rather than an ideal future state. Context maps need not show the detail of a model; instead, they must demonstrate the integration points and the flow of data between bounded contexts. Like the code model and analysis model, the context map should change only when code changes so it does not give a false impression of the landscape. The map should show the stark reality; only then will it be useful.

组织现实

The Organizational Reality

业务流程的变更或新工作流程的创建通常会跨越多个有界上下文，并影响到领域内的各个部分。协调这种规模的变更通常需要与技术变更一样多的团队管理。了解每个需要变更的上下文的负责人以及变更将如何进行至关重要。如果不了解变更的协调和优先级排序流程，这可能会成为一个巨大的绊脚石，并阻碍开发，因为团队需要等待其他人响应变更请求。显示团队关系的方向是上下文图优于传统 UML 或架构图的优势之一。在项目开始时掌握这些知识对于在非技术挑战阻碍进度之前解决它们至关重要。

Changes to business processes or the creation of new work flows can often span many bounded contexts and reach across various parts of the domain. Coordinating change on this scale often requires as much management of teams as it does technical change. It is vital to understand who is responsible for each context that is required to change and how this change will take place. If the process of coordination and prioritization of changes is not understood, it can be a massive stumbling block and stifle development as teams wait on others to act on requests for change. Showing the direction of team relationships is one of the strengths a context map has over traditional UML or architectural diagrams. Having this knowledge at the start of a project is essential to resolving nontechnical challenges before they block progress.

图 7.3展示了有界上下文之间关系的方向。对于不在同一项目的团队来说，如果需要对其职责范围之外的有界上下文进行变更，他们可能需要协调发布计划和开发优先级。技术变更可能相当简单，但如果不了解相关政策，其他上下文的变更可能会被推迟，甚至根本无法实施。

Figure 7.3 shows the direction of relationships between bounded contexts. Teams that are not on the same project might find release schedules and development priorities need to be aligned if a change is required to a bounded context outside their ownership. Technical change can be fairly straightforward, but if the political situation is not understood, changes to other contexts may be delayed or not implemented at all.

绘制相关现实

Mapping a Relevant Reality

创建上下文图时，请尽量关注当前的问题区域；您需要了解会影响项目成功的环境，而不是整个企业。只关注将直接集成的上下文，有助于您顺利开展上下文图工作，并防止失去焦点。

When creating a context map, try to focus on your immediate problem area; you need to understand the landscape that will affect the success of your project and not the entire enterprise. A focus only on the contexts that you will be directly integrating with helps you get going with context mapping and prevents you from losing focus.

X标记核心域的位置

X Marks the Spot of the Core Domain

在规划情境并识别实际应用的模型时，最好与领域专家合作，并标记核心领域。在地图上标记核心领域，并发现其与其他情境之间的关系，可以深入了解其在企业格局中的清晰定位。

When mapping out the contexts and identifying the models in play, it is a good idea to work with your domain experts and label the core domain. Marking the core domain on the map and discovering the relationships between it and other contexts can provide insight into its clarity in context to the enterprise landscape.

反腐败层

Anticorruption Layer

如果您正在为一个子系统创建模型，而该子系统又与其他子系统（作为大型系统的一部分）进行通信，则可能需要与不同团队创建的模型进行交互。即使是为同一领域创建的其他模型，也可能使用不同的通用语言来表达，并以与您自己的模型完全不同的方式进行建模。如果您在与这些模型集成时不够谨慎，那么适应它们的接口可能会导致模型损坏。

If you are creating a model for a sub system that communicates with other sub systems as part of a larger system you may need to interface with models created by different teams. Other models, even though created for the same domain, can be expressed with a different ubiquitous language and modelled in a completely different manner to your own. If you are not careful integrating with these models, adapting to their interfaces can lead to a corruption of your model.

为了避免损坏并保护您的模型免受外部影响，您可以创建一个隔离层，其中包含一个以您的模型编写的接口。该接口会适应并转换为其他上下文的接口。这个隔离层被称为防损坏层。

In order to avoid corruption and protect your model from external influences you can create an isolation layer that contains an interface written in terms of your model. The interface adapts and translates to the interface of the other context. This isolation layer is known as an anticorruption layer.

如图 7.4所示，您可以使用防腐层包装与遗留代码或第三方代码的通信，以保护有界上下文的完整性。防腐层管理一个上下文模型到另一个上下文模型的转换。

As shown in Figure 7.4, you can use an anticorruption layer to wrap communication with legacy or third-party code to protect the integrity of a bounded context. An anticorruption layer manages the transformation of one context’s model to another.

防腐层的转换映射的工作方式与适配器模式类似，它将另一个上下文的 API 转换为您可以操作的 API。第 11 章给出了使用防腐层在有界上下文之间进行转换的示例。

The anticorruption layer’s translation map works in a similar manner to the adapter pattern in that it transforms the API of another context into an API that you can work against. Chapter 11 gives an example of the transformation that occurs between bounded contexts using the anticorruption layer.

您不会总是在进行全新开发，因此经常需要与第三方或旧版上下文集成。由于您无法更改不属于您或无法轻松更改的上下文的 API，因此务必不要为了兼容其他上下文的 API 而损害有界上下文的完整性。

You won’t always be working on greenfield developments, so you will often need to integrate with third-party or legacy contexts. Because you can’t change the API of the contexts you don’t own or those that can’t be changed easily, it’s important not to compromise the integrity of your bounded context to match the API of another.

如果您有一个类似于 BBoM 的系统，并且需要引入额外的功能，那么直接添加代码并最终导致混乱的情况会很诱人；或者，您也可以在添加新功能的同时请求重写整个系统。这两种选择都不切实际，因为重写大型应用程序既耗时又有风险，而直接添加代码则会加剧维护难度。一个更务实的选择是依靠防腐层，它可以将新上下文与现有的代码混乱隔离开来。在这种情况下使用防腐层是一种很好的重构实践，因为您可以创建清晰的边界，而无需更新上下文中混乱的代码。

If you have a system that resembles a BBoM and you need to introduce additional functionality it is tempting to simply add code to it and in turn add to the mess; alternatively you can request to rewrite the entire system at the same time as adding the new feature. Neither of these two options is practical as it can be time consuming and risky to rewrite a large application, and simply adding to the mess can increase the maintenance nightmare. A more pragmatic option is to lean on the anticorruption layer, which can be used to isolate the new context from the existing code mess. Using an anticorruption layer in this context is a great refactoring practice because you are able to create clear boundaries without needing to update the mess of code that lives within a context.

共享内核

Shared Kernel

如果两个团队在同一个应用程序中紧密合作，在两个独立的有界上下文中，而这些上下文在领域概念和逻辑方面存在大量交叉，那么保持团队隔离并使用转换映射从一个上下文转换到另一个上下文的开销可能会过高。在这种情况下，协作并共享部分模型以简化集成可能是一个更好的选择。这种共享模型称为共享内核。如果同一子域中有两个有界上下文共享领域逻辑的子集，则该模式尤其适用。

If two teams are working closely in the same application, on two separate bounded contexts that have a lot of crossover in terms of domain concepts and logic, the overhead of keeping the teams isolated and using translation maps to translate from one context to another can be too much. In this instance, it may be better to collaborate and to share part of the model to ease integration. This shared model is known as a shared kernel. The pattern is of particular use if you have two bounded contexts in the same subdomain that share a subset of domain logic.

图 7.5显示了 ERP 系统的一部分，其中包含工资单上下文和共享员工模型的 HR 上下文。

Figure 7.5 shows part of an ERP system that contains a payroll context and an HR context that shares the employee model.

由于存在共享代码依赖关系，共享内核的风险可能更大，因为耦合度更高，可能导致一个团队破坏另一个团队的系统。重要的是，两个团队的每个人都必须理解这一点，并且当通用模型被修改时，持续集成测试系统能够验证两个模型的行为。

Because there is a shared code dependency, a shared kernel can be more risky due to the tighter coupling that leads to one team being able to break another team’s system. It’s important that everyone on both teams understands this and that a continuous integrated test system verifies the behavior of both models when the common model is modified.

开放主机服务

Open Host Service

与您通信的其他系统或组件会使用某种类型的转换层，以便将您的模型转换为它们自己的术语，类似于防腐层。如果多个消费者共享相同的转换逻辑，那么提供一组服务会更有用，这些服务通过明确定义的显式契约（称为开放主机服务）来公开上下文的功能。

Other systems or components that communicate with you will employ some type of transformation layer in order to translate your model into terms of their own, similar to the anticorruption layer. If multiple consumers share the same transformation logic it can be more useful to provide a set of services that exposes the functionality of a context via a clearly defined, explicit contract known as an open host service.

考虑图 7.6中的示例。订单管理系统向商务系统、采购系统和 CRM 系统提供有关客户订单的信息。每个系统都需要将复杂的订单管理系统的订单模型转换为在其自身系统中使用。为了避免这种重复工作，订单管理系统可以通过开放主机服务，使用已发布的语言公开简化版本的销售订单，如图7.7所示。

Consider the example in Figure 7.6. The order management system provides information about customer orders to the commerce system, procurement system, and the CRM system. Each system is required to translate the complicated order management system’s order model for use within their own system. To avoid this duplication of efforts the order management system can expose a simplified version of a sales order using a published language via an open host service, as shown in Figure 7.7.

《分道扬镳》

Separate Ways

如果由于技术复杂性或政策因素导致不同情境之间的集成成本过高，可以决定完全不进行集成，而只是让各个团队各自独立实施。集成可以通过用户界面或手动流程实现。例如，对于管理客户联系的客户服务应用程序来说，在处理客户查询时向用户显示未完成的订单可能很有用。但是，如果订单管理系统之间的集成工作量过大，那么更实际的做法可能是简单地添加一个菜单链接，允许在单独的屏幕中打开订单管理系统，从而为用户提供所需的信息，而无需完全集成的复杂性，尽管这会略微缩小功能需求的范围。

If the cost of integration between contexts is too great due to technical complexities or political ones, a decision can be made to not integrate contexts at all and simply have teams implement separately from one another. Integration can instead be achieved via user interfaces or manual processes. For example, it may be useful for a customer service application that manages contacts with customers to also show users the orders a customer has outstanding when dealing with a query. However, if the effort of integration between an order management system is too great it may be more practical to simply include a menu link that enables the Order Management system to be opened in a separate screen, thus giving users the information they need without the complexities of fully integrating albeit for a small de-scope in feature request.

合伙

Partnership

如果两个团队负责不同的上下文，但致力于实现共同目标，则可以建立合作伙伴关系，以确保在两个上下文之间进行集成合作。合作可以涵盖技术接口，以便兼顾双方的利益。从策略角度来看，两个团队可以协调发布，以便在需要时发布必要的接口和联系点。如果团队在两个限界上下文之间使用共享内核，建议他们以合作伙伴关系的方式进行。

If two teams are responsible for different contexts but are working toward a common goal a partnership can be formed to ensure that cooperation on integration between the two contexts can be made. Cooperation can cover the technical interfaces so that they accommodate both teams’ interests. From a political standpoint releases can be aligned between the teams so that necessary interfaces and contact points are released at a time that they are required. If teams are using a shared kernel between two bounded contexts it is recommended that they do so as a partnership.

上下游关系

An Upstream/Downstream Relationship

有界上下文之间的关系可以用方向来定义；一端是上游，另一端是下游。如果你是关系的下游端，那么依赖于上游端的数据或行为。上游端会影响下游环境。例如，如果上游接口发生变化，下游消费端也必须随之变化。同样，上游关系的发布计划也会影响下游环境，因为它可能依赖于特定的 API 方法。以下模式展示了如何对上下游关系进行分类。

The relationships between bounded contexts can be defined in terms of a direction; one end will be upstream and the other downstream. If you are the downstream end of the relationship you are dependent on data or behavior of the upstream end. The upstream end will influence the downstream context. For instance, if an upstream interface changes so must the consuming side downstream. Likewise the release plan of the upstream part of the relationship will influence the downstream context as it may be dependent on a particular API method. The following patterns show how the upstream and downstream relationships can be classified.

客户-供应商

Customer-Supplier

在团队未能朝着共同目标努力的情况下，为了避免上游团队包揽所有决策，并可能损害下游团队的利益，从而损害整个项目，可以建立更具协作性的客户-供应商关系。在这种模式下，团队将共同努力，创建一个在技术和调度方面均令人满意的、双方都认可的接口。这种关系中的客户部分指的是下游环境。客户将参加供应商（上游环境）的计划会议，以确保其需求得到理解，并能够及时了解上游发生的变化。

In situations where teams are not working toward a common goal to avoid the upstream team making all the decisions and potentially compromising the downstream team to the detriment of the project as a whole, a more collaborative customer-supplier relationship can be formed. In this pattern, the teams work together to create an agreed-upon interface that satisfies both from a technical and scheduling standpoint. The customer part of the relationship is the downstream context. The customer will join the supplier’s (upstream context) planning meeting to ensure its needs are understood and that it can have visibility when upstream changes are occurring.

由于客户/供应商关系协作的增加，决策时间可能会更长。团队需要召开会议或在线讨论才能取得进展。通过周密的规划，或许可以提前达成一致，这样就不会有团队因为等待其他团队做出决策或部署使用更新界面的新系统而陷入困境。另一方面，对于远程团队、跨时区团队或日程繁忙的团队来说，协作开销可能会导致长时间的延迟。

Due to the increased collaboration of the customer/supplier relationship, decisions can take longer. Teams need to have meetings or online discussions to progress. With careful planning, it might be possible to make agreements in advance so that no team is blocked waiting for the other to make a decision or deploy its new system with the updated interface. On the other hand, for remote teams, teams in different time zones, or teams with busy schedules, the collaboration overhead could cause lengthy delays.

客户-供应商关系强调客户团队的有界上下文依赖于供应商团队的有界上下文，但反之则不然。有时下游上下文没有机会与上游上下文建立合作关系，因此下游上下文必须遵循上游上下文的集成点。

The customer-supplier relationship emphasizes that the customer team’s bounded context relies on the supplier team’s bounded context, but not vice versa. Sometimes there is no opportunity to form a collaborative relationship with an upstream context and so the downstream context must conform to the upstream context’s integration points.

例如，如图 7.8所示，商务环境需要的销售订单信息比订单管理环境目前提供的要多。负责商务环境的团队可以在订单管理环境团队的规划会议期间充当客户的角色，以确保他们的需求得到理解和满足。

For example, consider Figure 7.8; the commerce context requires more information on a sales order than is currently supplied from the order management context. The team that is responsible for the commerce context can act as a customer during the order management context team’s planning sessions to ensure their needs are understood and accounted for.

保持诚信

Retaining Integrity

组织中的所有开发团队都需要了解上下文映射。团队无需了解每个有界上下文的内部工作原理；相反，他们需要了解其他上下文——它们公开的应用程序编程接口 (API)、它们之间的关系，以及最重要的，它们负责的概念模型。有了这些信息，团队可以避免责任界限模糊，并确保所有上下文都保持完整性。

All development teams in the organization need to understand the context map. Teams don’t need to understand the inner workings of each bounded context; instead, they need to be aware of those other contexts—the application programming interface (API) they expose, the relationships they have, and, most importantly, the conceptual models they are responsible for. With this information, teams can prevent blurring the lines of responsibility and ensure that all contexts retain their integrity.

保持完整性对于确保代码库专注于单一模型至关重要。这使得代码变得灵活，因为任何更改都只会影响单个有界上下文，而不会对业务领域的多个部分产生连锁反应。正是这种灵活性，让您能够修改代码，并在业务需要更改流程或逻辑时快速、自信地做出调整。

Retaining integrity is important to keep your codebase focused on a single model. This enables the code to become supple because any change affects only a single bounded context and doesn’t have a rippling effect across multiple areas of your domain. It’s this suppleness that enables you to alter code and to adapt quickly and confidently when the business needs a change to process or logic.

攻击计划的基础

The Basis for a Plan of Attack

上下文图突出显示了混乱和混乱的区域，更重要的是，它突出了核心领域的位置。团队可以使用这些信息来确定他们需要首先清理的区域，以提高项目的成功率：

A context map highlights areas of confusion and mess, and, more importantly, where the core domain is. Teams can use this information to identify areas they need to clear up first to improve the success of a project:

• 那些已经走得太远、需要付出的努力远远大于回报的领域可以被隔离并留下。
• Areas that are too far gone and where the effort to improve is far greater than the payback can be isolated and left.
• 没有战略优势或复杂程度较低的领域不需要花费创建通用语言的成本或遵循模型驱动的开发方法。
• Areas of no strategic advantage or that are of low complexity need not incur the cost of creating a ubiquitous language or follow the model-driven development methodology.
• 对于项目成功至关重要或复杂的领域是领域驱动设计战术方面的候选，并且应该与设计不良的有界上下文隔离以保持完整性。
• Areas that are core to the success of the project or are complex are candidates for the tactical side of Domain-Driven Design, and should be kept isolated from poorly designed bounded contexts to retain integrity.

理解所有权和责任

Understanding Ownership and Responsibility

问责制和责任制是可能影响项目的其他非技术领域。明确需要集成的子系统的团队所有权和管理权，对于确保变更按时完成并符合预期至关重要。上下文映射涉及调查和澄清；您可能无法立即绘制清晰的上下文映射，但明确责任、明确界定模糊界限以及在映射上下文时理解沟通流程的过程与最终的成果同等重要。

Accountability and responsibility are other nontechnical areas that can affect a project. Defining team ownership and management for subsystems that you need to integrate with is essential for ensuring changes are made on time and in line with what you expect. Context mapping is about investigation and clarification; you may not be able to draw a clear context map straight away, but the process of clarifying responsibility, explicitly defining blurred lines, and understanding communication flow while mapping contexts is as important as the finished artifact.

揭示业务工作流程中的混乱区域

Revealing Areas of Confusion in Business Work Flow

在有界上下文之间发生并利用有界上下文的业务流程，往往处于无人区，缺乏明确的职责，也缺乏清晰的边界和集成方法。上下文图侧重于关系的非技术层面，可以揭示系统和业务功能之间中断的业务流程和通信，这些流程和通信随着时间的推移而退化。这种揭示通常对能够更好地理解和改进跨部门和跨功能流程的企业更有用。这种洞察可以用来降低项目失败的风险，方法是及早解决模糊性问题，并提出有助于项目成功的有力问题。

The business processes that happen between and take advantage of bounded contexts are often left in no-man’s-land without clear responsibility and clarity regarding their boundaries and integration methods. A context map, focusing on the nontechnical aspects of the relationships, can reveal broken business process flow and communication between systems and business capabilities that have degraded over time. This revelation is often more useful to the businesses that are able to better understand and improve process that spans across departments and capabilities. The insight can be used to reduce risk of project failure by tackling ambiguity early and asking powerful questions that help the success of the project.

管理业务流程的环境之间的灰色区域在发生变更时也没有责任，并且只会在项目生命周期的后期才被发现。

The often gray area between contexts that govern business process is also void of accountability when changes are being made, and is only discovered later on in a project’s life cycle.

识别非技术障碍

Identifying Nontechnical Obstacles

上下文图揭示了项目涉及的部门边界。如果您的团队并非掌握所有相关上下文，则需要与其他团队和其他管理层进行协调并确定优先级。提前了解这些障碍可以大大提高项目成功的可能性，并使您能够在发布计划等非技术问题成为阻碍之前将其解决。

Context maps reveal the departmental boundaries involved in a project. If your team does not own all the contexts in play, coordination with other teams and other lines of management and prioritization needs to take place. Understanding these obstacles up front gives you a much greater probability of success on a project and enables you to tackle nontechnical problems such as release scheduling before they become blockers.

类似地，需要与第三方环境集成的更改可能会暴露对测试环境和与外部团队协调的要求，或者至少需要访问沙盒帐户和文档。

In a similar manner, changes that require integration with third-party contexts can expose requirements on testing environments and coordination with outside teams or at least access to sandbox accounts and documentation.

鼓励良好沟通

Encourages Good Communication

当图表显示你的有界上下文与另一个有界上下文之间存在关联时，你应该很清楚地知道需要与负责该上下文的团队进行沟通。当图表还显示你是上游团队时，你就会明白你的职责通常是领导决策，因此，你可能经常需要主动沟通。

When a diagram shows you that a relationship exists between your bounded context and another bounded context, you should have a pretty good idea that you need to be communicating with the team responsible for it. When the diagram also indicates that you are the upstream team, you understand that your responsibility is usually to lead decision making, and accordingly, you may often need to initiate communication.

帮助新员工入职

Helps On-Board New Starters

您是否曾经在一家新公司开始工作，却不明白自己的系统如何融入整个系统？您是否曾经因为领域专家向您提出的问题涉及到您几乎不了解的系统部分而感到不安？拥有一个简洁而信息丰富的上下文图，供整个团队定期查看并保持更新，是确保所有团队成员了解全局的绝佳方法，或者至少让他们了解自己对系统哪些部分了解不够。如果一位领域专家向您提出您不熟悉的问题，您可以参考上下文图，了解最适合咨询的对象。

Have you ever started working for a new company and not understood how your system fits into the system as a whole? Have you ever felt uneasy about answering questions from domain experts because they came to you with problems that also touched on parts of the system you barely knew existed? Having a concise, yet informative, context map that the whole team regularly views and keeps up to date is a fantastic way to ensure all team members understand the bigger picture—or at least have an idea of which parts of the system they don’t know enough about. If a domain expert approaches you with a problem that you’re unfamiliar with, you can turn to the context map for suggestions about who it would be best to talk to.

分离应用程序的关注点

Separating the Concerns of Your Application

为了避免代码库变成“大泥球”（BBoM），从而削弱领域模型的完整性和最终实用性，应用程序的结构必须支持将技术复杂性与领域复杂性分离。应用程序的呈现、持久化和领域逻辑关注点会以不同的速率和原因发生变化；分离这些关注点的架构可以适应变化，而不会对代码库中不相关的部分造成不良影响。

To avoid turning your codebase into a Big Ball of Mud (BBoM) and thus weakening the integrity and ultimately the usefulness of a domain model, it is vital that the structure of an application supports the separation of technical complexities from the complexities of the domain. Presentation, persistence, and domain logic concerns of an application will change at different rates and for different reasons; an architecture that separates these concerns can accommodate change without causing an undesired effect to unrelated areas of the codebase.

从领域复杂性中抽象出来

Abstraction from the Complexities of the Domain

除了关注点分离之外，应用程序架构还必须通过公开一组粗粒度的用例来抽象化复杂领域的复杂性，这些用例封装并隐藏了底层领域细节。更高层次的抽象可以防止领域逻辑的更改影响表示层，反之亦然，因为应用程序的客户端通过充当用例的应用服务进行通信，而不是直接与领域对象进行通信。

In addition to a separation of concerns, an application architecture must abstract away from the intricacies of a complex domain by exposing a coarse-grained set of use cases that encapsulate and hide the low-level domain details. Abstracting at a higher level prevents changes in domain logic from affecting the presentation layer and vice versa because the clients of the application communicate through application services acting as use cases rather than directly with domain objects.

分层架构

A Layered Architecture

为了支持关注点分离，您可以对应用程序的不同职责进行分层，如图 8.1所示。Fowler 在其著作《企业应用程序架构模式》中对无处不在的分层架构进行了分类。然而，许多其他架构也通过将应用程序划分为共同变化的区域来支持关注点分离，例如 Bob 大叔的清洁架构、六边形架构（也称为端口和适配器架构）以及洋葱架构。

To support the separation of concerns, you can layer the different responsibilities of an application, as shown in Figure 8.1. Fowler catalogued the ubiquitous layered architecture in his book Patterns of Enterprise Application Architecture. However, many other architectures support the separation of concerns by dividing an application into areas that change together, such as Uncle Bob’s Clean Architecture, the Hexagonal Architecture (also known as the Ports and Adapters Architecture), and the Onion Architecture.

与典型的分层架构视图不同，图 8.1显示，该架构的核心是领域层，它包含与业务相关的所有逻辑。领域层周围是一个应用层，它抽象了领域的底层细节，并将其置于粗粒度的应用程序编程接口 (API) 之后，这些 API 代表了应用程序的业务用例。领域逻辑层和应用层相互隔离，并免受任何客户端、框架和基础设施问题带来的意外复杂性的影响。

Unlike typical views of a layered architecture, Figure 8.1 shows that at the heart of the architecture is the domain layer containing all the logic pertaining to the business. Surrounding the domain layer is an application layer that abstracts the low-level details of the domain behind a coarse-grained application programming interface (API) representing the business use cases of the application. The domain logic and application layers are isolated and protected from the accidental complexities of any clients, frameworks, and infrastructural concerns.

依赖倒置

Dependency Inversion

为了强制实现关注点分离，架构中心的领域层和应用层不应依赖于任何其他层。所有依赖关系都面向内部，因此，作为应用程序核心的领域层不依赖于任何其他层，使其能够专注于领域关注点，不受任何干扰。应用层仅依赖于领域层；它通过委托给领域层来协调用例的处理。

To enforce a separation of concerns, the domain layer and application layers at the center of the architecture should not depend on any other layers. All dependencies face inward, in that the domain layer, at the heart of the application, is dependent on nothing else, enabling it to focus distraction-free on domain concerns. The application layer is dependent only on the domain layer; it orchestrates the handling of the use cases by delegating to the domain layer.

当然，领域对象的状态需要保存到某种持久化存储中。为了在不将领域层与技术代码耦合的情况下实现这一点，应用层定义了一个接口，该接口允许领域对象进行数据融合和持久化。该接口从应用层的角度编写，采用应用层能够理解的语言和风格，不受特定框架或技术术语的束缚。然后，基础架构层实现并适配这些接口，从而在不耦合的情况下提供下层所需的依赖关系。事务管理以及安全性和日志记录等横切关注点也以相同的方式提供。图 8.2展示了依赖关系的方向和接口的方向，它们描述了应用层和技术层之间的关系。

Of course, the state of domain objects needs to be saved to some kind of persistence store. To achieve this without coupling the domain layer to technical code, the application layer defines an interface that enables domain objects to be hydrated and persisted. This interface is written from the perspective of the application layer and in a language and style it understands free from specific frameworks or technical jargon. The infrastructural layers then implement and adapt to these interfaces, thus giving the dependency that the lower layers need without coupling. Transaction management along with cross-cutting concerns such as security and logging are provided in the same manner. Figure 8.2 shows the direction of dependencies and the direction of interfaces that describe the relationship between the application layer and technical layers.

领域层

The Domain Layer

如第四章所述，领域模型代表了问题域的概念抽象视图，旨在满足业务用例的需求。包含抽象模型的领域层不依赖于任何其他内容，并且与它所服务的客户端以及用于持久化领域对象的数据存储的技术细节无关。

As discussed in Chapter 4 a domain model represents a conceptual abstract view of the problem domain created to fulfill the needs of the business use cases. The domain layer containing the abstract model does not depend on anything else and is agnostic to the technicalities of the clients it serves and data stores that persist the domain objects.

应用服务层

The Application Service Layer

应用服务层代表应用程序的用例和行为。用例被实现为包含应用逻辑的应用服务，通过委托给领域层和基础架构层来协调用例的执行。应用服务在比领域对象更高的抽象级别上运行，公开一组粗粒度的服务，同时隐藏领域层的细节——系统做什么，但不知道如何做。通过将领域的复杂性隐藏在外观层之后，您可以改进领域模型，同时确保更改不会影响客户端。

The application service layer represents the use cases and behavior of the application. Use cases are implemented as application services that contain application logic to coordinate the fulfillment of a use case by delegating to the domain and infrastructural layers. Application services operate at a higher level of abstraction than the domain objects, exposing a coarse-grained set of services while hiding the details of the domain layer—what the system does, but not how it does it. By hiding the complexities of the domain behind a façade, you can evolve the domain model while ensuring that changes do not affect clients.

领域层的客户端是应用服务层；然而，为了执行其工作，它需要依赖外部层。这些依赖关系是反向的，因为应用层将契约暴露给它所需的接口。外部资源必须适应这些接口，以确保应用层不会与特定技术紧密耦合。

The client of the domain layer is the application service layer; however, to perform its work, it requires dependencies on external layers. These dependencies are inverted because the application layer exposes the contracts to the interfaces it requires. The external resources must then adapt to the interfaces to ensure the application layer is not tightly coupled to a specific technology.

应用服务层负责协调从数据存储中检索领域对象、将工作委托给这些对象，然后保存更新后的状态。应用服务层还负责在领域内发生重大事件时协调向其他系统的通知。所有这些与外部资源的接口都在应用服务层中定义，但在基础架构层中实现。

Coordinating the retrieval of domain objects from a data store, delegating work to them, and then saving the updated state is the responsibility of the application service layer. Application service layers are also responsible for coordinating notifications to other systems when significant events occur within the domain. All these interfaces with external resources are defined within the application service layer but are implemented in the infrastructural layer.

应用服务层能够在不损害领域层完整性的情况下支持不同的客户端。新客户端必须适应应用程序契约（即 API）定义的输入。它们还必须将应用服务的输出转换为适合自己的格式。这样，应用层就可以被视为一个防腐层，确保领域层保持纯粹，不受外部技术细节的影响。

The application service layer enables the support of disparate clients without compromising the domain layer’s integrity. New clients must adapt to the input defined by the application’s contract—its API. They must also transform the output of the application service into a format that is suitable for them. In this way, the application layer can be thought of as an anticorruption layer, ensuring that the domain layer stays pure and unaffected by external technical details.

基础设施层

The Infrastructural Layers

应用程序的基础架构层是使其能够正常运行的技术细节。应用层和领域层分别专注于建模行为和业务逻辑，而基础架构层则关注纯粹的技术功能，例如使应用程序能够被用户使用，无论是由人类通过用户界面，还是由应用程序通过一组 Web 服务或消息端点访问。基础架构层还负责存储领域对象状态信息的技术实现。

The infrastructural layers of an application are the technical details that enable it to function. Whereas the application and domain layers are focused on modeling behavior and business logic, respectively, the infrastructural layers are concerned with purely technical capabilities, such as enabling the application to be consumed, whether by humans via a user interface or by applications via a set of web service or message endpoints. The infrastructural layers are also responsible for the technical implementation of storing information on the state of domain objects.

此外，基础架构层还可以提供日志记录、安全、通知以及与其他有界上下文和应用程序集成的功能。这些都是外部细节——技术问题，不应直接影响暴露的用例和应用程序的领域逻辑。

In addition, the infrastructural layer can provide capabilities for logging, security, notification, and integration with other bounded contexts and applications. These are all external details—technical concerns that should not directly affect the use case exposed and the domain logic of an application.

跨层通信

Communication Across Layers

跨层通信时，为了防止将领域模型的细节暴露给外界，请勿跨层传递领域对象。出于同样的原因，请勿将未经请求的原始数据或用户输入直接发送到领域层。相反，您可以使用简单的数据传输对象 (DTO)、演示模型和应用程序事件对象来传达领域中的更改或操作。

When communicating across layers, to prevent exposing the details of the domain model to the outside world, you don’t pass domain objects across boundaries. For the same reasons, you don’t send raw unsolicited data or user input straight into the domain layer. Instead, you use simple data transfer objects (DTOs), presentation models, and application event objects to communicate changes or actions in the domain.

为了避免层与层之间紧密耦合，高层必须通过适配低层的消息类型来与其通信。这又一次保持了低层与外部层的隔离和松散耦合。图 8.3展示了跨层通信以及如何转换数据以保护领域模型的完整性。

To avoid tight coupling of layers, higher layers must communicate with lower layers by adapting to their message types. This again keeps the lower layers isolated and loosely coupled to any external layers. Figure 8.3 shows the communication across the layers and how data is transformed to protect the integrity of the domain model.

隔离测试

Testing in Isolation

分离应用程序中的不同关注点并确保域逻辑不依赖于任何技术重点代码（例如演示或数据持久性框架），使您能够独立于任何基础架构框架来测试域和应用程序逻辑。

Separating the different concerns in your application and ensuring your domain logic is not dependent on any technically focused code such as presentation or data persistence frameworks enables you to test domain and application logic in isolation, independent of any infrastructural frameworks.

如图 8.4所示，您可以使用单元测试来确认领域层内的逻辑。您可以使用模拟和存根为应用层提供所需的虚假实现，以确认业务任务与领域层和外部资源协调的正确性。

As shown in Figure 8.4, you can use unit tests to confirm the logic within the domain layer. You can use mocks and stubs to give the application layer the fake implementations it requires to confirm the correctness of business task coordination with the domain layer and external resources.

不要在有界上下文之间共享数据模式

Don’t Share Data Schema between Bounded Contexts

除了在应用程序代码库中分离关注点之外，架构还必须将领域对象状态的持久性与其他应用程序的数据需求分离。图 8.5展示了通过共享数据库和共享模式集成的应用程序。

In addition to separating the concerns within the codebase of an application, an architecture must include the separation of the persistence of the domain object state from other applications’ data requirements. Figure 8.5 shows applications integrated via a shared database and shared schema.

虽然这是一种简单的集成方法，但它可能会使模型变得复杂，模糊其界限，因为它会成为代码库发展成 BBoM 的催化剂。共享数据使得客户端代码很容易绕过有界上下文的保护，并在没有领域逻辑保护的情况下与领域对象状态进行交互。此外，还很容易错误地解释逻辑和模式，导致状态更改，从而使不变量失效。

Although this is an easy integration method, it can complicate and blur the lines of a model by acting as the catalyst to your codebase growing into a BBoM. Sharing data makes it easy for client code to bypass the protection of a bounded context and interact with a domain object state without the protection of domain logic. It is also easy to interpret logic and schema incorrectly, resulting in changes to the state that invalidate invariants.

如图 8.6所示，您应该优先使用应用数据库或有界上下文数据库，而不是集成数据库。正如您在领域模型中应用上下文边界一样，您必须对持久化模型执行同样的操作。这有助于强制客户端通过定义明确的应用服务层进行集成，从而保护模型的完整性并确保满足不变量。

As shown in Figure 8.6, you should favor application or bounded context databases over integration databases. Just as you apply context boundaries within the domain model, you must do the same for the persistence model. This helps to force clients to integrate through the well-defined application service layer, protecting the integrity of your model and ensuring invariants are met.

应用程序架构与有界上下文架构

Application Architectures versus Architectures for Bounded Contexts

应用程序可以由多个有界上下文组成。架构以不同的方式应用于有界上下文和应用程序。由两个或多个有界上下文组成的应用程序可能具有针对用户界面的架构风格，并且每个有界上下文可能具有不同的架构风格。图 8.7展示了一个由三个有界上下文组成的应用程序；其中，表示层包含其自己的应用层，以便于与有界上下文进行协调。

Applications can be composed of more than one bounded context. Architectures apply to bounded contexts and applications in different ways. An application that is composed of two or more bounded contexts may have an architectural style for the user interfaces and different architectures for each of the bounded contexts. Figure 8.7 shows an application composed of three bounded contexts; here the presentation layer contains its own application layer to facilitate the coordination with the bounded contexts.

然而，有些人认为有界上下文的边界应该延伸到表示层。Udi Dahan 的业务组件赋予了有界上下文拥有用户界面特定区域的责任。该架构如图 8.8所示。

However, some people believe that the boundary of a bounded context should extend to the presentation layer. Udi Dahan’s business component gives the bounded context the responsibility for owning specific regions of the user interface. This architecture can be seen in Figure 8.8.

在这种架构风格中，基础设施负责确保通信和关联 ID 的共享。

In this architecture style, the infrastructure takes care of ensuring communication and the sharing of correlation IDs.

跨有界上下文的架构风格或数据存储不需要保持一致，但在单个有界上下文中，您应该努力遵循一种表示域逻辑的方法。

There does not need to be consistency in architectural styles or data stores across bounded contexts, but within a single bounded context, you should strive to follow one method of representing domain logic.

应用逻辑与领域逻辑

Application Logic versus Domain Logic

应用逻辑包含实现业务用例所需的工作流步骤。这些步骤包括从数据库中提取领域对象、将用户输入映射到领域层能够理解的对象，以及最终委托领域对象或其集合来做出业务决策。其他步骤可能包括委托基础架构服务，例如通过消息传递系统或 Web 调用通知其他系统领域状态的变化、授权和日志记录。

Application logic contains the workflow steps required to fulfill a business use case. Steps can include the hydrating of domain objects from a database, the mapping of user input to objects that the domain layer understands, and ultimately the delegating to domain objects or a collection of them to make a business decision. Other steps may include delegating to infrastructural services, such as notifying other systems of changes in domain state via messaging systems or web calls, authorization, and logging.

应用逻辑的核心是通过委托给领域和基础架构服务来进行协调和编排。应用服务本身不执行任何工作，但它们知道应该与谁交互才能完成任务。而领域逻辑则只关注领域规则、概念、信息和工作流程。领域逻辑不受技术细节（包括持久化）的影响。

Application logic is all about coordination and orchestration through delegation to domain and infrastructural services. The application services don’t do any work, but they understand who to talk to to complete the task. Domain logic, on the other hand, is focused only on domain rules, concepts, information, and work flows. Domain logic is free from technical details, including persistence.

举例来说，请考虑图 8.9，它模拟了将促销优惠券应用于电子商务购物篮的用例。ASP.NET MVC 框架表示层将超文本传输​​协议 (HTTP) 请求转换为应用服务层期望的形式，并调用服务方法。应用服务委托持久层检索优惠券对象。然后，它检查优惠券是否仍然有效。如果无效，则返回相应的结果。如果有效，它再次委托持久层检索购物篮，并将购物篮传递给优惠券以生成折扣。购物篮域对象上的折扣更改将被持久化，并发布事件通知优惠券已被兑换。

As an example, consider Figure 8.9, which models the use case of applying a promotion coupon to an e-commerce basket. The ASP.NET MVC framework presentation layer transforms the Hypertext Transport Protocol (HTTP) request into a form that the application service layer expects and calls the service method. The application service delegates to the persistence layer to retrieve the coupon object. It then checks whether the coupon is still valid. If it is not, it responds with an appropriate result. If it is valid, it again delegates to the persistence layer to retrieve the basket and passes the basket to the coupon to generate a discount. The changes to the discount on the basket domain object are persisted, and an event is published to notify that the coupon was redeemed.

定义和公开功能

Defining and Exposing Capabilities

由于应用服务暴露了系统的功能，因此它们无需适应新的客户端。相反，新的客户端（例如表示层）应该适应服务暴露的契约。换句话说，系统的功能不应该为了客户端而改变。相反，它们应该只在业务用例发生变化时才进行更改。应用服务公开的用例与用于实现它们的领域逻辑相比，其变化速率和原因各不相同。这使得使用这些服务的客户端能够免受领域逻辑频繁变化的影响。

Because the application services are exposing capabilities of the system, they should not have to adapt to new clients. Instead, new clients, such as presentation layers, should adapt to the contracts exposed by the services. In other words, the capabilities of the system should not change for clients. Rather, they should change only when the business use case changes. The use cases exposed by the application services change at a different rate and for different reasons than the domain logic that is used to fulfill them. This enables clients consuming the services to be protected from frequent changes to domain logic.

以评估订单欺诈风险的业务用例为例。系统公开了获取订单详细信息并根据领域逻辑返回评分的功能。随着时间的推移，领域逻辑可能会发生变化，但作为该用例的实现（用于对订单进行风险评分）的应用服务将基本保持不变，只会在修改其合约以提供更多信息时发生变化。

Take, for example, the business use case of risk assessing an order for fraud. The system exposes the capability to take details of an order and return a score based on domain logic. Over time, the domain logic may change, but the application service that is the implementation of the use case to score an order for risk will largely remain constant, changing only to alter its contract to provide additional information.

利益相关者可能不了解领域层的复杂性；然而，应用层负责的业务任务对业务来说意义重大。即使利益相关者不是领域专家，他们也应该理解这些任务。

The stakeholders may not know the complexities of the domain layer; however, the business tasks that the application layer is responsible for are meaningful to the business. Even if they are not domain experts, the stakeholders should understand them.

业务用例协调

Business Use Case Coordination

领域模型本质上是面向对象的，而应用服务则是过程化的，因为它们专注于任务编排，而不是领域逻辑和概念的建模。应用服务与 ASP.NET MVC 控制器操作有些相似。控制器操作包含控制用户界面交互的逻辑，其方式与应用服务包含表示业务任务或用例的逻辑相同，这些任务或用例用于协调与领域层内的服务和对象的通信。控制器操作和应用服务本质上都是无状态的和过程化的。一个例外是，控制器操作和应用服务都可以存储状态，但该状态应该仅用于存储客户旅程的状态或业务任务的进度。

Whereas the domain model is object-oriented in its nature, the application services are procedural, as they are focused on task orchestration as opposed to modeling domain logic and concepts. Application services are somewhat similar to ASP.NET MVC controller actions. Controller actions contain logic to control the user interface interactions in the same manner that application services contain logic that represents business tasks or use cases that coordinate communication with services and objects within the domain layer. Both controller actions and application services are stateless and procedural in nature. An exception is that both controller actions and application services can store state, but the state should only be to store the status of the customer journey or the progress of the business task.

应用服务还以转换和映射输入输出的形式与控制器操作共享更多协调逻辑。控制器操作将 HTTP POST 变量映射到应用服务所需的对象，并将应用服务查询响应映射到视图模型以满足呈现需求。同样，应用服务将请求映射到领域对象能够理解的结构中，并使用隐藏领域对象真实形式且特定于用户界面视图的呈现模型进行响应。

Application services also share more coordination logic with controller actions in the form of transforming and mapping input and output. Controller actions map HTTP post variables to objects that application services require and map application services query responses to view models for presentation needs. Application services, in the same way, map requests into structures that domain objects understand, and respond with presentation models that hide the real form of the domain objects and that are specific to user interface views.

应用服务代表用例，而不是创建、读取、更新和删除

Application Services Represent Use Cases, Not Create, Read, Update, and Delete

行为驱动设计 (BDD) 可帮助您理解应用程序的行为。通过 BDD 捕获的行为，您可以使用 BDD 规范中表达的语言作为应用服务用例的名称。这类似于在领域层代码中使用领域通用语言 (UL) 的方式。应用服务不仅仅是创建、读取、更新和删除 (CRUD) 方法；它们应该揭示用户意图并传达系统的功能。第 25 章“命令：用于处理业务用例的应用服务模式”中提供了这方面的示例，以及如何实现应用服务层的模式。

Behavior-Driven Design (BDD) helps you understand the behaviors of an application. With the behaviors you capture using BDD, you can use the language expressed in the BDD specifications as the name for you application services use/cases. This is similar to the way you use the ubiquitous language (UL) of the domain within the code of the domain layer. Application services are not simply create, read, update, and delete (CRUD) methods; they should reveal user intent and communicate the capabilities of a system. Examples of this can be seen in Chapter 25, “Commands: Application Service Patterns for Processing Business Use Cases,” along with patterns on how to implement the application service layer.

领域层作为实现细节

Domain Layer As an Implementation Detail

应用服务功能强大，可以解决任何应用程序的复杂性，无论是具有丰富逻辑的核心子域，还是仅仅是访问数据的外观的通用子域存储。通过应用服务将客户端与逻辑分离，可以使域层干净地发展，而不会在各层之间产生连锁反应。

Application services are powerful and can be helpful for any application complexity, be it a core subdomain with rich logic or a generic subdomain that is merely a façade for access to the data store. Having the application services decouple clients from the logic enables the domain layer to evolve cleanly without having a ripple effect across layers.

您的应用服务方法可以揭示是否需要领域模型。如果您发现所有业务用例都只是简单地更新、添加或删除数据，那么很可能该领域缺乏任何真正的逻辑，可以通过使用事务脚本或数据包装器模式（如第二章“提炼问题领域”）来保持简单，而不是使用成熟的富领域模型。但是，如果您系统的应用服务和行为语言丰富，这可能表明您的领域逻辑层需要领域模型模式。

Your application service methods can reveal whether a domain model is required at all. If you find that all your business use cases are simply updating, adding, or deleting data, then it’s a good bet that the domain is lacking any real logic and can be kept simple by employing a transaction script or data wrapper pattern, as discussed in Chapter 2, “Distilling the Problem Domain,” instead of a full-blown rich domain model. However, if the application services and behaviors of your system are rich in language, this may suggest the need for a domain model pattern in your domain logic layer.

域名报告

Domain Reporting

除了协调业务任务之外，应用服务层还需要以报告的形式提供领域对象的状态信息。您不希望将领域模型的内部工作原理暴露给外界，因此应用服务会将领域对象转换为呈现模型，以便在不暴露领域模型结构的情况下提供领域状态的具体视图。您可以在图 8.10中看到这种转换。

Besides coordinating business tasks, the application service layer needs to provide information on the state of domain objects in the form of reports. You don’t want to expose the inner workings of your domain model to the outside world, so the application services transform domain objects into presentation models that give specific views of domain state without revealing the structure of the domain model. You can see this transformation in Figure 8.10.

读取模型与事务模型

Read Models versus Transactional Models

有时，用户界面需要跨多个领域对象的信息。如果应用服务将所有丰富的领域对象聚合起来，仅仅为视图提供一部分信息，效率低下且成本高昂。在这种情况下，应用服务层最好直接从数据源提供领域状态的特定视图，如图 8.11所示。这样，您就可以高效地构建视图，而无需构建领域对象的大型对象图并公开其中的详细信息。

Sometimes a user interface requires information that spans across many domain objects. It would be inefficient and costly for the application service to hydrate all the rich domain objects to simply provide a subset of information for a view. In these cases, it is preferable for the application service layer to provide a specific view of domain state directly from the data source, as shown in Figure 8.11. This way, you can construct views in an efficient manner without having to construct large object graphs of the domain objects and expose details within them.

然而，从同一概念模型（尽管是数据模型）提供读写功能存在一个缺点。事务模型将逻辑存储在域对象中，将简单状态存储在数据存储中。为了同时支持报表和事务需求，视图可能需要额外的信息，这会影响域对象的结构。为了防止模型因演示需求而发生更改，您可以将视图数据单独存储在最适合查询的数据模式中。为此，您可以存储领域模型中发生的变化并将其用作报告需求的基础。

There is, however, a drawback to providing read and write capabilities from the same conceptual model, albeit the data model. The transactional model stores logic in domain objects and simple state in the data store. To support both reporting and transactional needs, the views might require extra information that will affect the structure of domain objects. To prevent the model from having to change because of presentation needs, you can store the view data separately in a data schema that is best suited to querying. To achieve this, you can store changes that occur within the domain model and use these as the basis for reporting requirements.

图 8.12展示了事务模型如何处理来自客户端的写入请求，然后引发存储以供查询的事件。您可以将这些事件及其数据存储在同一个数据库中，也可以存储在完全不同的存储机制中。这种模式称为命令查询职责分离 (CQRS)，第 24 章“CQRS：有界上下文的架构”将更详细地介绍。第 26 章“查询：领域报告”将介绍更多用于领域模型报告的模式。

Figure 8.12 shows how the transactional model handles a write request from a client and then raises events that are stored for querying. You can store these events and their data in the same database or a completely different storage mechanism. This pattern is called Command Query Responsibility Segregation (CQRS) and is covered in greater detail in Chapter 24, “CQRS: An Architecture of a Bounded Context.” Further patterns for reporting on a domain model are presented in Chapter 26, “Queries: Domain Reporting.”

对所有有界上下文使用相同的架构

Using the Same Architecture for All Bounded Contexts

DDD 并不强制要求框架、工具集或应用程序架构。您无需使用 CQRS、事件溯源、事件驱动、RESTful 服务、消息传递或对象关系映射器即可应用 DDD 原则。然而，它坚持的一点是，领域模型的复杂性与技术代码的复杂性必须相互独立。任何支持这一点的架构都非常适合 DDD。领域逻辑和技术复杂性的变化速度不同；因此，组织这些不同的上下文是管理复杂性的关键。

DDD does not dictate a framework, tool set, or application architecture. You don’t have to use CQRS, event sourcing, event-driven, RESTful services, messaging, or object-relational mappers to apply the principles of DDD. What it does insist on, though, is that the complexity of your domain model is kept isolated from the complexities of your technical code. Any architecture that supports this is a good fit for DDD. Domain logic and technical complexity change at different rates; as a result, the organization of these different contexts is key to managing complexity.

架构是有界上下文的，而非特定于应用程序的。对于简单且低复杂度的有界上下文，架构师可以采用分层设计，并在领域层使用事务脚本模式。对于协作性更强的领域，可以使用 CQRS，而对于复杂的领域，则更倾向于使用富领域模型模式。

Architectures are bounded context and not application specific. The architect for a simple bounded context with low complexity could be composed of a combination of a layered design with the transaction script pattern for the domain layer. A more collaborative domain could employ CQRS, and a complex domain would favor the rich domain model pattern.

追求战术模式的完美

Striving for Tactical Pattern Perfection

只关心编写代码的团队会专注于 DDD 的战术模式。他们把构建块模式视为圣经而非指南，却不了解何时可以打破规则。他们浪费精力去遵守模式规则。这些精力最好用来理解为什么需要编写这些规则。DDD 的重点在于发现需要编写什么、为什么需要编写以及应该投入多少精力。如前所述，DDD 的战术模式是自 Eric 的书出版以来发展最快的元素，而 DDD 的战略方面则始终忠实于 Eric Evan 的原著。如何开发团队创建领域模型远不如理解首先要编写什么模型以及如何在有界上下文中开发它们那么重要。理解解决问题的内容和原因比如何在代码中实现它更重要。

Teams concerned only with writing code focus on the tactical patterns of DDD. They treat the building block patterns as a bible rather than a guide, with no understanding of when it’s okay to break the rules. They spend wasted effort adhering to the rules of the patterns. This energy is better spent on understanding why it needs to be written in the first place. DDD is about discovering what you need to write, why you need to write it, and how much effort you should use. As mentioned before, the tactical patterns of DDD are the elements that have evolved the most since Eric’s book was written, with the strategic side of DDD remaining faithful to Eric Evan’s original text. How development teams create domain models is not nearly as important as understanding what models to write in the first place and how to develop them in a bounded context. Understanding the what and the why of problem solving is a more important process than how you are going to implement it in code.

误将构建块视为 DDD 的价值

Mistaking the Building Blocks for the Value of DDD

许多 DDD 项目失败的原因在于，他们选择了 DDD 的战术模式，却忽略了其战略和协作层面。团队没有花时间与业务部门进行知识交流。他们没有专注于领域模型和细致的抽象。他们没有建立通用语言 (UL)。仅使用 DDD 的战术模式语言被称为 DDD 精简版。遵循 DDD 精简版方法固然可行，但这并非秉持 DDD 哲学。误以为自己正在应用 DDD 的团队将会错过 DDD 的诸多价值所在：协作、UL 和有界上下文。仅仅关注辅助建模设计的模式，会忽略解决问题的全局视角。

Many DDD projects fail because the tactical patterns of DDD are picked, but the strategic and collaborative sides of DDD are neglected. Teams do not take the time to knowledge-crunch with the business. They do not concentrate on the domain model and on careful abstractions. They don’t establish a ubiquitous language (UL). Using only the tactical pattern language of DDD is known as DDD lite. Following a DDD lite approach is fine, but this is not embracing the DDD philosophy. Teams mistakenly thinking that they are applying DDD will be missing out on much of where the value of DDD lies: collaboration, UL, and bounded contexts. Focusing only on the patterns to aid the modeling design omits the bigger picture of problem solving.

相比之下，DDD 的许多战略模式可用于创建任何中大型业务系统，无论其底层复杂度如何。事实上，所有战略模式都有很多好处，包括确定是否应该定义 UL 以及是否应该使用战术模式。子域可以帮助分解复杂的问题域，从而促进沟通并确定重要内容。上下文图揭示了不同上下文之间的集成点以及团队之间的关系。然而，有时很难证明将领域模型模式应用于复杂或不断发展的领域以外的任何领域是合理的。

In contrast, many of the strategic patterns of DDD can be used in the creation of any medium-to-large-scale business system regardless of the underlying complexity. In fact, all the strategic patterns have many benefits, including identifying whether a UL should be defined and whether the tactical patterns should be used at all. Subdomains can help break down complex problem domains to aid communication and identify what is important. Context maps reveal integration points between different contexts along with the relationships between teams. However, it is sometimes difficult to justify the tactical patterns of applying the domain model pattern to anything other than a complex or constantly evolving domain.

关注代码而不是 DDD 原则

Focusing on Code Rather Than the Principles of DDD

软件开发论坛上最常见的问题之一是：我可以看看示例应用程序吗？可能有很多优秀的解决方案可以展示在 DDD 流程下开发的产品的结果，但仅仅检查代码工件并不能充分展现 DDD 的诸多优势。DDD 的实践往往是在白板上、咖啡里，以及在走廊里与业务专家一起进行的；当一些小的重构突然揭示出一个隐藏的领域概念，并由此提供更深入洞察的关键时，它就显现出来了。示例应用程序无法展现领域专家与开发团队之间的多次对话和协作。

One of the most often-asked questions on software development forums is this: Can I see a sample application? There are probably many good solutions that show the result of a product developed under a DDD process, but much of the benefit of DDD is not revealed when you only examine the code artifact. DDD is performed on whiteboards, over coffee, and in the corridors with business experts; it manifests itself when a handful of small refactorings suddenly reveal a hidden domain concept that provides the key to deeper insight. A sample application does not reveal the many conversations and collaborations between domain experts and the development team.

代码工件是数月辛勤工作的成果，但它仅代表最后一次迭代。代码本身在达到今天的样子之前，可能已经经历了多次修改。随着时间的推移，代码将继续演进以支持不断变化的业务需求；今天有用的模型可能与产品未来迭代中使用的模型截然不同。

The code artifact is the product of months and months of hard work, but it only represents the last iteration. The code itself would have been through a number of guises before it reached what it resembles today. Over time, the code will continue to evolve to support the changing business requirements; a model that is useful today may look vastly different to the model used in future iterations of the product.

如果您希望模仿 DDD 的理念，并以此来审视一个按照 DDD 方法构建的解决方案，那么您将无法体会到其中的很多原则和实践，而且会过于强调代码的构建块。事实上，如果您不熟悉领域，您就会发现底层领域模型的表达能力并不强。

If you were to view a solution that had been built following a DDD approach hoping to emulate the philosophy, a lot of the principles and practices would not be experienced, and too much emphasis would be placed on the building blocks of the code. Indeed, if you were not familiar with the domain, you would not find the underlying domain model very expressive.

DDD 确实规定了一系列设计最佳实践、模式和构建块，这些常常被误认为是将 DDD 应用于产品的核心。相反，可以考虑这些设计工件仅仅作为一种手段来表示概念模型。DDD 的核心在于开发团队和领域专家之间的协作，以生成有用的模型。

DDD does prescribe a set of design best practices, patterns, and building blocks that are often mistakenly thought to be core to applying DDD to a product. Instead, think of these design artifacts as merely a means to an end used to represent the conceptual model. The heart of DDD lies deep in the collaboration between the development team and domain experts to produce a useful model.

由于低估了上下文的重要性而产生了巨大的混乱

Producing a Big Ball of Mud Due to Underestimating the Importance of Context

上下文、上下文、上下文，还是更多上下文。这是 DDD 中的一个基本概念。上下文可以帮助您组织大型问题域的解决方案。并非所有问题都能用同一个模型来解决。需要创建各种模型来解决不同的问题。在定义的上下文边界内创建模型对于保持代码可管理并避免其变成“大泥球”（BBoM）至关重要。了解上下文的结束和开始位置是上下文图的职责。如果没有上下文概念和上下文图的指导，团队将无法交付价值，因为他们需要不断地与混乱无序的代码库作斗争。

Context, context, context, and more context. It’s a fundamental concept in DDD. Context helps you organize solutions for large problem domains. All problems cannot be solved using the same model. Various models need to be created to solve different problems. Creating models within defined context boundaries is essential to keep your code in a manageable state and avoid it turning into a Big Ball of Mud (BBoM). Understanding where contexts end and begin is the responsibility of a context map. Without the notion of context and a context map to guide you, teams cannot deliver value because they are constantly fighting the unorganized mess of their codebase.

如果团队不了解其他环境，他们所做的更改可能会影响到其他环境。如果团队不清楚模型的边界，就有可能破坏其概念的完整性。模型之间适用性的界限模糊或缺失，往往会导致模型合并，从而很快形成BBoM。上下文图对于理解边界线以及如何维护模型的完整性至关重要。

If teams don’t understand other contexts, changes they make may bleed into those other contexts. Teams without a clear understanding of the boundaries of a model risk violating its conceptual integrity. Blurred or no lines of applicability between models often results in a merging of models, which quickly leads to a BBoM. A context map is vital to understanding boundary lines and how to uphold the integrity of models.

造成遗留代码和技术债务的最大问题在于代码的组织方式。代码编写起来很容易，但如果不仔细考虑其结构，阅读起来就会变得极其困难。了解上下文可以帮助您隔离不相关的概念，从而使模型更加纯粹和专注。这就像在架构层面应用单一职责原则 (SRP)。更易于维护和阅读的代码将使团队能够更快地交付价值，这正是 DDD 的精髓。

The biggest issue that contributes to legacy code and technical debt is how it’s organized. Code is easy to write, but without due care and attention to how it is structured, it can become extremely hard to read. Understanding about context enables you to isolate unrelated concepts so that models are more pure and focused. Think about it like applying the Single Responsibility Principle (SRP) but at an architectural level. Code that is easier to maintain and read will allow teams to deliver value faster, which is the essence of DDD.

识别领域专家在不同语境下讨论但仍使用相同术语的情况。如果在业务中使用相同的术语，很容易陷入认为模型可以重复使用的陷阱。警惕用于多个语境的隐式模型。最好创建显式模型。将“不要重复自己”（DRY）原则应用于有界上下文仅仅是一个概念，而不是一个系统。不要害怕在不同的语境中使用相同的概念和名称。团队需要知道的最重要的事情是，他们应该保护自己的边界。

Recognize when domain experts are talking in a different context but still using the same terms. If the same terms are used within the business, it is easy to fall into the trap of thinking that the models can be reused. Beware implicit models that are used for more than one context. It’s better to create explicit models. Apply the principle of Don’t Repeat Yourself (DRY) to a bounded context only and not a system. Don’t be afraid to use the same concepts and names in different contexts. The most important thing teams need to know about is that they should protect their boundaries.

未能创建 UL 导致歧义和误解

Causing Ambiguity and Misinterpretations by Failing to Create a UL

有效的沟通对于理解和解决问题领域内的挑战至关重要。如果没有良好的沟通，开发团队和领域专家之间的协作就无法蓬勃发展。不重视共享语言必要性的团队可能会使用技术抽象，并使用他们自己的共享技术语言构建模型。当团队寻求帮助或验证其模型时，他们需要将其翻译成领域专家能够理解的形式。在最好的情况下，这种翻译会成为开发的瓶颈；在最坏的情况下，它可能导致团队围绕不重要或领域专家不理解的概念和主题进行构建。

Effective communication is essential for understanding and solving challenges within the problem domain. Without strong communication, collaboration between the development team and domain expert cannot flourish. Teams that do not value the need for a shared language are likely to employ technical abstractions and build a model using their own shared technical language. When the teams seek help or validation on their model, they are required to translate it for domain experts to understand. At best, this translation is a bottleneck for development; at worst, it can end up with the team building around concepts and themes that are not important or that the domain experts do not understand.

没有共享的语言，就无法创建共享的模型。这种对问题的共同愿景能够捕捉隐含的概念，并协作解决问题。创建语言的过程是开发团队和领域专家协作的直接结果。能够轻松解决问题并理解问题领域正是回报的来源。

Without a shared language, you cannot create a shared model. This shared vision of the problem enables the capturing of implicit concepts and collaborative problem solving. The process of creating a language is a direct result of collaboration between the development team and domain experts. Being able to easily solve problems and understand the problem domain is where the payoff comes from.

如果没有 UL，上下文就很难发现，因为有界上下文主要由语言的适用性定义。没有上下文和明确语言的模型很快就会变成 BBoM，因为同名概念会被建模成一个。

Without a UL, contexts are hard to discover, because a bounded context is primarily defined by the applicability of language. Models created without context and explicit language quickly turn into a BBoM as concepts with the same name are modeled as one.

语言的制定会对业务和产品开发产生重大影响。它有助于明确定义通用概念，并且像模式语言一样，在讨论复杂的领域逻辑和业务功能时消除歧义。

The formulation of a language can have a big impact on a business and product development. It helps to explicitly define common concepts, and just like a pattern language, remove ambiguity when talking through complex domain logic and business capabilities.

有了 UL，领域专家可以在实施领域模型时像开发团队一样提供软件问题的解决方案。

With a UL, domain experts can offer solutions to software problems when implementing the domain model as much as the development teams themselves.

由于缺乏协作，设计以技术为中心的解决方案

Designing Technical-Focused Solutions Due to a Lack of Collaboration

如果没有协作，问题领域的关键概念可能会被忽略，而一些易于理解的概念可能会被过分强调。在组织内部，领域的重要方面往往是隐含的；没有与领域专家合作的团队可能会忽略这些方面，转而关注领域名词等更容易理解的内容。如果没有协作来验证理解并揭示暗示的概念，开发团队将围绕技术术语进行抽象，而业务用户将需要翻译才能理解解决方案领域中的问题与问题领域之间的关系。

Without collaboration, key concepts of the problem domain can be missed, and easy-to-understand concepts can be overemphasized. Within an organization, important facets of a domain are often implicit; teams not working with domain experts can overlook these, instead focusing on the lower-hanging fruit like the nouns of a domain. Without collaboration to validate understanding and reveal hinted-at concepts, development teams will abstract around technical terms, and business users will require translation to understand how the problems in the solution space relate to the problem space.

协作的意义在于让许多持有不同观点的人齐心协力，共同创建一个可用于解决问题的问题域模型。没有人拥有绝对的权威，也没有哪个建议是愚蠢的。

Collaboration is all about getting lots of people with different points of view working on creating a model of the problem domain that can be used to solve problems. No one has the authority on a good idea, and no suggestion is stupid.

试图与领域专家以外的任何人合作进行知识处理可能会徒劳无功。可以充当领域专家代理的业务分析师将能够向您提供需求并传达输入和输出，但他无法协助塑造模型来满足用例。

Trying to collaborate on knowledge crunching with anyone other than a domain expert can be a wasted effort. A business analyst who may act as a proxy for a domain expert will be able to give you requirements and communicate inputs and outputs, but he will not be able to assist with shaping a model to fulfill the use cases.

将 DDD 原则应用于业务期望不高的简单领域

Applying DDD Principles to a Trivial Domain with Little Business Expectation

简单的问题需要简单的解决方案。那些对企业没有战略优势的琐碎领域或子领域，无法从 DDD 的所有原则中获益。那些热衷于将 DDD 原则应用于任何项目（无论问题领域的复杂程度如何）的开发人员，很可能会遇到业务同事的不满，因为他们对那些不太重要的业务领域漠不关心。

Simple problems require simple solutions. Trivial domains or subdomains that do not hold a strategic advantage for businesses will not benefit from all the principles of DDD. Developers who are keen to apply the principles of DDD to any project regardless of the complexity of the problem domain will likely be met with frustrated business colleagues who are not concerned with the less important areas of a business.

DDD 是一套原则，旨在帮助您管理对业务具有重大优势的复杂问题域。业务预期较低的问题应该以平淡无奇的方式处理。这并不是说这些问题应该以杂乱无章的方式构建。相反，这些问题应该构建得高性能且易于维护，但逻辑性较差的问题则需要直接的解决方案。

DDD is a set of principles to help you manage complex problem domains that hold significant advantage for a business. Problems with a low business expectation should be tackled in a no-thrills manner. This is not to say that they should be built in a haphazard manner. On the contrary, they should be built to be performant and maintainable, but problems that have little logic need straightforward solutions.

大型复杂系统会包含许多子域，其中一些包含对产品战略重要性至关重要的复杂逻辑，而另一些则仅仅是用于管理数据的表单，复杂度很低甚至没有。DDD 的战术模式以及协作构建 UL 来传达模型应该只用于核心子域。这些领域需要清晰地理解，以支持快速变更，或用于建模复杂且内在的逻辑。团队不应在通用域或子域上浪费精力，而应确保它们能够正常工作并与核心域隔离。

Large complex systems will have many subdomains, some containing complex logic key to strategic importance of a product, whereas others will simply be forms to manage data with little or no complexity. The tactical patterns of DDD along with collaborating to build a UL to communicate models should be reserved for the core subdomains only. These are the areas that need to be clear to aid rapid change or that model complicated and intrinsic logic. Teams should not waste energy on the generic domains or subdomains beyond keeping them working and isolated from the core domains.

忽视 CRUD 作为一种反模式

Disregarding CRUD as an Antipattern

并非所有系统都设计精良；试图完善整个代码库可能会徒劳无功。你的注意力和精力应该放在核心领域，因为其他任何好的部分都足够好。对于领域逻辑很少或没有领域逻辑、数据结构仅包含表单的系统，可以选择更简单的架构，例如基于创建、读取、更新和删除 (CRUD) 的系统，以减少时间投入并提高核心领域的可用性。

Not all of your system will be well designed; trying to perfect an entire codebase can be wasted effort. Your focus and energy should be on the core domain, for anything else good is good enough. For systems with little or no domain logic and with no more than forms over data opt for a simpler form of architecture such as a create, read, update, and delete (CRUD)-based system to decrease time spent and increase availability for the core domain.

为每个有界上下文使用领域模型模式

Using the Domain Model Pattern for Every Bounded Context

领域模型模式对于复杂或频繁变化的模型非常有用。对于通用或缺乏领域逻辑的模型，采用领域模型模式所需的工作量将远远大于其获得的价值。对于核心领域，应使用模型驱动设计和领域模型模式，而对于系统中较简单的部分，则使用其他领域逻辑模式。

The domain model pattern is useful for complex or frequently changing models. The effort required to employ the domain model pattern for models that are generic or lack domain logic will be far greater than any value that will be gained. Utilize model-driven design and the domain model pattern for the core domain, and use other domain logic patterns for simpler parts of your system.

问问自己：这种额外的复杂性值得吗？

Ask Yourself: Is It Worth This Extra Complexity?

初级开发人员学习设计模式时，会试图将其应用到自己编写的每一段代码中。这种行为在团队学习领域驱动设计 (DDD) 时也经常出现。他们只关注 DDD 的战术模式，盲目地将这些模式应用到每个项目中，无论其合理性如何。这种急于应用新理念而不充分考虑该流程是否值得为软件付出的努力，可能会导致不必要的复杂性，而其实一个简单的解决方案就足够了。

When junior developers learn about design patterns, they try to apply them to every piece of code they write. This behavior is often seen when teams learn about DDD. They focus only on the tactical patterns of DDD, blindly applying these patterns to every project regardless of whether it is justified. This eagerness to apply a new philosophy without due consideration as to whether the process is a worthwhile endeavor for the software can lead to needless complexity where a simple solution would have sufficed.

如果现成的软件就足够了，就不要开发非战略性的软件。如果将手动流程自动化太费力，那就直接手动操作吧。记住：解决方案不一定非得是技术性的。

Don’t develop nonstrategic software if off-the-shelf software will suffice. If the effort to automate a manual process is too great, just leave it manual. Remember: Solutions don’t always have to be technical.

在没有积极进取、专注的团队的情况下尝试取得成功

Trying to Succeed Without a Motivated and Focused Team

DDD 并非适合所有人。它当然也并非适合所有项目。为了在遵循 DDD 的过程中获得最大收益，您需要一个可以长期投入的复杂核心领域、一个迭代式开发流程，以及与领域专家的沟通。然而，这并非全部。您还需要掌握许多其他技能才能在 DDD 中取得成功。为了有效地运用 DDD，您需要具备以下技能：

DDD is not for everyone. It is certainly not the right fit for every project. To gain the most benefit when following DDD, you need a complex core domain that will be invested in over time, an iterative development process, and access to domain experts. However, that is not all that is required. There are a number of other skills that you need to succeed at DDD. To be effective at DDD, you need the following:

• 重构所需的可靠设计原则
• Solid design principles required for refactoring
• 敏锐的设计感
• Sharp design sense
• 专注、积极、经验丰富的团队
• A focused, motivated, and experienced team

您需要训练有素的开发人员，他们愿意与领域专家合作并了解业务，而不是担心如何将最新的 JavaScript 框架融入到项目中。

You need disciplined developers who are willing to work with domain experts and understand the business rather than worry how they can wedge the latest JavaScript framework into a project.

记住：DDD 并非灵丹妙药。正如从前期瀑布式开发方法转向更敏捷/XP 的项目方法并不能解决所有软件开发问题一样，选择遵循 DDD 也不会一下子就创造出更好的软件。任何成功项目的共同点在于拥有一支由聪明人组成的团队，他们对自己的工作充满热情，并致力于项目的成功。

Remember: DDD isn’t a silver bullet. Just as switching from an upfront waterfall approach to a more agile/XP project methodology didn’t solve all your software development problems, opting to follow DDD won’t suddenly produce better software. The common denominator in any successful project is a team of clever people who are passionate about what they are doing and who care about it succeeding.

当领域专家不在项目背后时尝试合作

Attempting Collaboration When a Domain Expert Is Not Behind the Project

业务所有权和投资，尤其是来自领域专家的投入，是成功合作的关键。如果开发团队与那些对项目缺乏投入或不理解项目意图或愿景的领域专家合作，他们就不太可能找到有用的模型、创建最终用户指南 (UL)，也无法组成一支高效的团队。开发团队擅长设计系统来应对问题领域的挑战。然而，当与领域专家合作时，他们可以更进一步，通过从源头上解决问题并重新定义业务流程，共同努力，从而消除对软件解决方案的需求。

Business ownership and investment especially from domain experts is key to successful collaboration. If a development team is working alongside domain experts who are not invested in the project or do not understand the intent or vision, they will unlikely discover a useful model, create a UL, and work as an effective team. Development teams are great at designing systems to handle challenges in the problem domain. However when collaborating with a domain expert, they can go further and work together to remove the need for software solutions by removing issues at the source and redefining business processes.

非迭代开发方法中的学习

Learning in a Noniterative Development Methodology

DDD 的核心在于头脑风暴，在于协作学习。它意味着不要止步于你的第一个想法，而是要不断尝试，直到发现更好的方案，或者仅仅验证你最初的想法。所有这些都需要时间，不支持这些方法论就无法支持 DDD。

DDD is about brainstorming. It’s about collaborative learning. It’s about not stopping at your first idea but continuing to experiment so you discover something better or simply to validate your initial idea. All this takes time, and a methodology that doesn’t support this can’t support DDD.

一次尝试不可能创造出一个有用的模型；因此，需要一种迭代开发方法来完善设计。模型会不断发展。如果团队不理解模型和语言仅在特定时间内有效，他们创造的有用成果很快就会变成一堆BBoM。模型需要呵护。随着对领域洞察的加深以及新用例对模型的挑战，模型需要不断完善和重构。

A useful model will not be created on the first attempt; therefore, an iterative development methodology is required to hone a design. Models evolve. Teams that don’t appreciate that the model and language are only valid for a given time will quickly see their useful creation turn into a BBoM. A model needs love. It needs to be refined and refactored as more insight into the domain is gained and as new use cases challenge the model.

值得注意的是，为了实验和改进模型，你需要单元测试的安全性。这并不是说你必须遵循测试驱动的流程；而是你必须确保你的代码在一系列重构之后仍然有效。

It’s also worth noting that, to experiment and evolve a model, you need to have the safety of unit tests. That is not to say that you must follow a test-driven process; instead, you must ensure your code can be valid after a series of refactors.

将 DDD 应用于每个问题

Applying DDD to Every Problem

每个解决方案都必须对应一个合适的问题。DDD 是一种适用于特定问题空间的设计理念。它是你工具箱中必备的利器。但是，如果您的业务并不复杂或变化不频繁，那么不要轻易动用 DDD：记住，你的开发工具包中还有其他更合适的工具。只需将你的建模工作和 DDD 重点放在最复杂的、能为客户带来最大价值的有界上下文上即可。

For every solution, there must be an appropriate problem. DDD is a design philosophy suited to a particular problem space. It is a great tool to have in your toolbox. However, if your business is not complex or isn’t changing frequently then don’t automatically reach for the DDD hammer: remember there are other better suited tools in your development tool kit. Only focus your modeling efforts and DDD on the most complex bounded contexts that bring the most value to your customer.

并非所有子域都很复杂。有些域或上下文甚至可能不需要完整的域模型，可能只包含一些没有业务逻辑的数据，只需要基本的 CRUD 操作。对于低复杂度的上下文，建议使用基于 CRUD/Active Record/事务脚本的应用程序，并将 DDD 的战术模式留给系统中对客户重要、复杂且频繁变化的部分。

Not all subdomains are complex. Some domains or contexts may not even need a fully fledged domain model and may just contain data with no business logic that simply requires the basic CRUD operations. For low-complexity contexts, favor the use of a CRUD/Active Record/Transaction Script-based application, and leave the tactical patterns of DDD for parts of your system that are important to your customer, that are complex, and that change frequently.

问问自己：这些额外的努力是帮助你交付解决方案，还是拖慢了你的进度？保持简单，但不要过于简单。不要过度设计解决方案，也不要试图利用无用的框架。保持简单是一门艺术，需要练习和务实的心态。

Ask yourself: Is this extra effort helping you deliver your solution, or is it slowing you down? Keep things simple but not simplistic. Don’t over engineer a solution or try to leverage unhelpful frameworks. Keeping things simple is an art form and takes practice and a pragmatic mind-set.

为了不必要的纯粹性而牺牲实用主义

Sacrificing Pragmatism for Needless Purity

不要在不必要的领域追求完美。对于通用或支持子域，请保持简单、直接和不复杂。使用 CRUD 和简单的域逻辑模式。编写可运行的代码；然后转到核心域。核心域是您可以追求完美的领域。在不重要的限界上下文中，小泥球有时效果更好；它们可以快速编写代码并将其排除在外。如果您需要更改它，您可以覆盖它。对于产品中不重要、不太可能更改或随着时间的推移投入的领域，优先考虑可运行的代码而不是完美的代码。好的通常就足够了。不要担心您是否做得对或开始寻求确认；这会浪费精力并分散注意力。将纯粹性留给重要的领域。

Don’t try to strive for perfection in areas that don’t need it. For generic or supporting subdomains, keep things simple, straightforward, and uncomplicated. Use CRUD and simple domain logic patterns. Get the code written so it works; then move on to the core domain. The core domain is the area where you can strive for perfection. Small balls of mud are sometimes better in bounded contexts that are unimportant; they get the code written quickly and get it out of the way. If you need to change it, you can overwrite it. For areas of your product that are unimportant, unlikely to change or be invested in over time, favor working code over perfect code. Good is often good enough. Don’t worry if you are doing it right or start to seek confirmation; this will be wasted effort and a distraction. Leave purity for the areas that count.

寻求认可只会浪费精力

Wasted Effort by Seeking Validation

当你遵循 DDD 原则构建系统时，你不会收到 Eric Evans 邮寄的证书来祝贺你的成就。盲目遵循任何模式、语言或方法论而不考虑自身独特的环境都是愚蠢的。仅仅为了遵循某种方法论而试图遵循一套规则是一种反模式。DDD 哲学并非遵循一套规则或应用编码模式。它是一个学习的过程。学习的过程远比目标重要，而学习的重点在于与领域专家合作探索你的问题领域，而不是在解决方案中运用多少设计模式。

When you build a system following the principles of DDD, you do not receive a certificate in the post from Eric Evans congratulating you on your achievement. Blindly following any patterns language or methodology without considering your own unique context is foolhardy. Trying to adhere to a set of rules for no other reason than to compile with a methodology is an antipattern. The DDD philosophy is not about following a set of rules or applying coding patterns. It is a process of learning. The journey is far more important than the destination, and the journey is all about exploring your problem domain in collaboration with domain experts rather than how many design patterns you can employ in your solution.

搜索论坛并阅读 DDD 博客文章，了解团队如何与业务部门协作，以促进学习并增加发现。不要试图创建完美的存储库模式，也不要向未直接参与项目的同事寻求确认，因为如果没有完整的背景信息，您必须轻视任何建议。

Search forums and read DDD blog posts to discover how teams are collaborating with the business to aid learning and increase discoveries. Don’t try to create the perfect repository pattern, and don’t seek confirmation from your peers who aren’t involved directly in your project because without the full context, you must take any advice lightly.

始终追求优美的代码

Always Striving for Beautiful Code

那些执着于应用设计模式和原则而不顾实际需求的团队，很可能会创建过于复杂且令人困惑的架构，从而从一开始就偏离产品的目标。团队应该理解设计模式背后的动机，并明智地运用它们。盲目地采用 DDD 的战术模式，对业务没有任何价值。

Teams that obsess with applying design patterns and principles regardless of the actual need will likely create overly complex and confusing architectures that miss the goal of the product in the first place. Teams should understand the motivations behind design patterns and use them judiciously. Blindly employing the tactical patterns of DDD does nothing to add value for the business.

在频繁变化的重要领域进行灵活的设计，有助于模型的灵活性和演进能力，而不会产生大的连锁反应。在那些几乎没有商业价值且不会被投入的领域，煞费苦心地追求优雅的设计，纯粹是浪费精力。与其费力地追求处处追求优美的代码，不如将一些小的“泥球”与其他易于替换的上下文隔离开来。

A supple design in important areas that frequently change aids a model’s ability to be flexible and evolve without having large rippling effects. Painstakingly striving for elegant design in areas that offer little business value and will not be invested in is a waste of efforts. It is far better to have small balls of mud, isolated from other contexts that can easily be replaced, rather than trying to strive for beautiful code everywhere.

在核心领域工作时，团队在确定某种模式和思维方式之前，当然应该等待一段时间。推迟重构，并尝试使用代码来发现哪些因素最容易导致摩擦/变化，可以揭示更多关于该领域的信息，并最终做出更明智的设计选择。

When working in the core domain, teams should certainly wait before committing to a pattern and a way of thinking. Delaying refactoring and living with the code to see what causes friction/changes the most can reveal more about the domain and lead to a more informed design choice.

不要被模式、框架或方法论所迷惑；它们只是实现细节。你的目标是更深入地理解你的领域，以便更好地解决其中的问题。这才是 DDD 的真正价值。

Don’t be distracted by patterns, frameworks, or methodologies; they are implementation details. Your goal is to understand your domain at a deeper level to be best equipped to solve problems within it. This is the true value of DDD.

DDD 是关于提供价值

DDD Is About Providing Value

不要让设计模式和原则妨碍你完成任务并为业务创造价值。模式和原则是指导你创建灵活设计的指南。在应用程序中使用它们的次数越多，荣誉勋章就越少。DDD 的重点是提供价值，而不是编写优雅的代码。

Don’t let design patterns and principles get in the way of getting things done and providing value to the business. Patterns and principles are guides for you to produce supple designs. Badges of honor will not be given out the more you use them in an application. DDD is about providing value, not producing elegant code.

教育你的团队

Educating Your Team

在向团队传达 DDD 的理念时，重点不应放在模式语言上，而应放在与业务的契合度、战略环境的重要性以及用于描述模型的语言上。战略 DDD 的原则和模式远比战术模式强大得多，也更有用。一个只关注软件模式的团队会错失 DDD 的真正价值，并且很可能付出应用这些实践的成本而得不到回报。

When communicating the philosophy of DDD to your team, focus not on the pattern language but instead on the alignment with the business, the importance of strategic contexts, and the focus on language used to describe a model. The principles and patterns of strategic DDD are far more powerful and useful than the tactical patterns. A team focused solely on the software patterns will miss the true value of DDD and will likely pay the cost of applying the practices without reaping the rewards.

技术并非解决业务问题的方案，它仅仅是一个实现细节。问题解决需要与领域专家合作，他们掌握着发现有用模型的关键。该模型在卡片或白板上进行头脑风暴，然后在 Visual Studio（或您最喜欢的 IDE）中实现。请记住：技术可能会使问题解决变得复杂；专注于一个不受基础设施和技术问题困扰的抽象概念模型，将使团队能够构建一个能够传达领域意图并被业务部门理解的解决方案。

Technology is not the solution to business problems; it is merely an implementation detail. Problem solving is achieved through collaboration with domain experts who hold the key to discovering a useful model. This model is brainstormed on cards or a whiteboard before being implemented in Visual Studio (or your favorite IDE). Remember: Technology can complicate problem solving; focusing on an abstract conceptual model free from the clutter of infrastructure and technical concerns will enable teams to build a solution that communicates the intent of the domain and can be understood by the business.

与您的企业对话

Speaking to Your Business

您的业​​务利益相关者并不想听到最新的开发理念或方法；他们只希望您能为他们创造价值。敏捷、面向服务架构 (SOA) 和云计算都被过度炒作，承诺解决所有开发问题，但却未能如愿。相反，您应该只谈论您希望深入了解您所在的业务，从而创造更多价值。谈论开发团队需要更加贴近业务愿景和目标。利益相关者会看到开发团队花时间与业务专家沟通，并根据业务期望进行调整的价值。

Your business stakeholders don’t want to hear about the next new development philosophy or methodology; they just want you to deliver value for them. Agile, Service-Oriented Architecture (SOA) and the cloud have all been overhyped, promising to solve all development problems but failing to do so. Instead, talk only of your desire to learn more about the business you work within to give more value. Talk of the need for the development team to be more aligned to the vision and intent of the business. A stakeholder will see the value in the development team spending time with business experts and aligning themselves to the expectations of the business.

如果没有领域专家的投入，DDD 就无法奏效。如果您能向利益相关者清晰地阐明聘请业务专家的重要性，那么您就为成功做好了准备。当然，您可以自由地与利益相关者讨论 DDD，但最好专注于协作的需求。产品的成功取决于业务部门及其专家的投入程度；这就是您推广 DDD 的方式。让团队深入了解问题域逻辑，能够帮助他们打造出更优秀的产品。

DDD does not work without the commitment of domain experts. If you can articulate the importance of having an expert from the business available to your stakeholders, you are setting yourself up to succeed. Of course, you are free to talk to your stakeholders about DDD, but it’s best to focus on the need for collaboration. The success of a product falls on the commitment level of the business and its experts; this is how you sell DDD. Empowering a team with a deep understanding of the problem domain logic enables it to produce a better product.

了解愿景

Understand the Vision

在收集需求之前，务必确保你的团队与利益相关者的期望保持一致。与利益相关者会面时，可以先提出一些开放式问题，阐明你选择自行开发而非购买产品的原因，并帮助解释产品的愿景。以下问题非常有用：

Before capturing requirements, it’s important to align your team with stakeholders’ expectations. Start a meeting with a stakeholder by asking open questions that draw out the reason you are opting to build rather than buy a product, and that help to explain the vision of the product. The following questions are powerful:

• 该产品的业务目标/驱动力是什么？
• What is the business goal/driver for this product?
• 该产品能给企业带来什么价值？
• What value will this product bring to the business?
• 你怎么知道这是否成功？好的形象是什么样的？
• How will you know if this is a success? What does good look like?
• 这与以前的做法有何不同？
• How is this different from what has been done before?

通过倾听利益相关者的提问，您可以确定产品中最重要的部分——软件领域，也就是您构建该产品的根本原因。捕捉这些信息，并创建一个领域愿景声明，让您的团队朝着共同的目标迈进。您的团队需要了解产品的成败因素、关键要素以及价值所在。

By listening to the stakeholder answering your questions, you can identify the most important part of the product—the area of the software that is the fundamental reason you are building it. Capture this information and create a domain vision statement that aligns your team to a common goal. Your team needs to understand what will make or break the product, what is essential, and where the value is.

在会议期间，您可能会发现该产品并非独一无二，实际上只是一个通用解决方案，只是内部开发更具成本效益。如果是这样，请明确说明这一点，并理解其对业务及其未来的重要性。也可能这是一款快速失败的产品——一个用来测试客户需求的原型。这些洞察将帮助您了解其价值所在以及业务目标。有了这些理解，您就可以确定所有 DDD 实践是否对您的项目有效。

During the meeting, you may discover that the product is not special and is in fact a generic solution that just happens to be more cost effective to build in-house. If so, make that explicit, and understand its importance to the business and its future. It could also be the case that this is a fail-fast product—a prototype to test the appetite of customers. These insights will enable you to understand where the value lies and what the business is trying to achieve. With this understanding, you can determine if all the practices of DDD are going to be effective for your project.

一旦您理解并分享产品的意图和利益相关者的目标，您就可以捕捉产品的特性，同时始终与产品的整体愿景保持一致。

Once you understand and share the intent of the product and the stakeholders’ goals, you can capture the features of the product while always aligning to the overall vision of the product.

捕捉所需的行为

Capture the Required Behaviors

在收集需求时，让利益相关者参与进来的一种有效方法是应用行为驱动开发 (BDD) 方法。BDD 是一种共享语言，可以帮助您捕获系统的行为。您可以将其视为需求的 UL。它使您的团队能够从非技术角度理解利益相关者的需求。实践 BDD 并专注于使用业务人员能够理解且能够明确体现价值的语言来捕获需求，这很好地展示了共享语言在促进沟通方面的强大作用。此过程有助于让团队了解语言的力量以及语义模糊的危害。利用这些环节来明确定义术语。此练习将为团队成员在 UL 上协作描述模型做好准备，该模型将实现满足系统行为所需的规则、逻辑和流程。

An effective way to engage stakeholders when gathering requirements is to apply the behavior-driven development (BDD) methodology. BDD is a shared language that helps you capture the behaviors of a system. You can think of it as a UL for requirements. It enables your team to understand the requirements from your stakeholder from a nontechnical perspective. The practice of BDD and the focus on capturing requirements in a language the business understands and which explicitly shows value is a great exercise in demonstrating the power of a shared language to aid communication. This process helps to educate the team on the power of language and the evil of ambiguity in meaning. Use these sessions to explicitly define terminology. This exercise will warm up the team members for when they collaborate on a UL to describe the model that will implement the rules, logic, and processes needed to satisfy the system’s behaviors.

你从利益相关者那里获取的是用例、输入和输出。这些业务用例构成了你的应用服务。如果它们很复杂，它们将决定你将实现哪种领域逻辑模式。在需求收集过程中，重点关注利益相关者的需求、时间以及原因。“为什么”至关重要。提出问题有助于验证利益相关者为什么想要他所说的内容。在需求阶段，请停留在问题空间，并专注于该产品将带来的机会。如何满足需求可以等到你理解并分享愿景之后再谈。

What you are capturing from the stakeholders are use-cases, inputs, and outputs. These business use cases form your application services. If they are complex, they drive the decision on what domain logic pattern you will implement. During requirements gathering, focus on what the stakeholder wants, when, and why. The why part is essential. Asking the question helps to validate why the stakeholder wants what he says. During the requirements stage, stay in the problem space, and focus on the opportunities that this product is going to bring. How you are going to satisfy the requirements can wait until you understand and share the vision.

我见过很多团队匆匆忙忙地处理需求，急于在未充分探究问题的情况下就直接跳到解决方案。不要操之过急地跳到解决方案；务必与利益相关者一起探索问题空间。利益相关者通常不清楚自己到底想要什么。通过探索问题空间，您可以找出真正的业务需求，并通常提供更好的行为，避免浪费时间去解决业务实际上并不存在的需求。

I have seen many teams rush through requirements, eager to jump to a solution without fully exploring the problem. Don’t jump to a solution too quickly; ensure that you explore the problem space with your stakeholders. Often, stakeholders are unclear on exactly what they want. By exploring the problem space, you can draw out the real business need and often offer better behaviors before wasting time on solutions to needs the business doesn’t really have.

当你开始生成充满功能的故事卡时，你可能会发现产品规模变得过于庞大，难以管理，或者问题空间中出现了模糊性。你也可能忽略了产品的整体情况以及开发该产品的核心原因。当这种情况发生时，就需要对问题空间进行提炼。

As you start to generate story cards full of features, you may find that the size of the product is becoming too big to manage or ambiguity is occurring in the problem space. You might also be losing sight of the bigger picture and the core reason that this product is being built. When this occurs, the problem space needs to be distilled.

了解景观的现实

Understand the Reality of the Landscape

在彻底理解问题空间并明确系统价值所在后，您就可以开始构建解决方案了。然而，在开始为任何项目创建解决方案之前，至关重要的是要了解您将要工作的环境。了解已投入生产的软件解决方案的状态，对于就如何集成产品做出明智的决策至关重要。捕捉全局的最佳方法是创建上下文图。

With a thorough understanding of the problem space and an alignment on where the value of the system is, you can start to model a solution. However, before you start creating a solution to any project, it’s of utmost importance to understand the environment that you will be working in. Understanding the state of the software solutions already in production is essential to making informed decisions on how you will integrate your product. The best way to capture the landscape is by creating a context map.

团队需要识别正在运行的不同有界上下文，这些上下文会直接影响你的产品，或者受你的产品影响。团队需要确定这些上下文如何交互、它们通过哪些协议集成以及它们管理哪些数据。为此，请遵循以下步骤：

The team needs to identify the different bounded contexts in play that will directly affect or be affected by your product. The team needs to identify how these contexts interact, what protocols they integrate through, and what data they manage. To achieve this, follow these steps:

1. 确定团队已知的哪些模型会直接影响或受问题区域影响。绘制这些上下文，命名它们，并说明谁负责它们。如果您不确定从哪里开始，请查看您所在领域的组织结构，因为大多数系统都是围绕部门沟通构建的。然后查看开发团队的结构。
2. Determine what models the team is aware of that directly affect or will be affected by the problem area. Draw these contexts, name them, and show who is responsible for them. If you are not sure where to start, look at the organizational structure of the domain you are working in, because most systems are built around departmental communication. Then look at the development team structures.
3. 绘制集成点和集成方法。
4. Map the integration points and methods of integration.
5. 映射交换的数据及其所有者。
6. Map the data that is exchanged and who owns it.
7. 标记上下文之间的关系。你的团队是位于下游并依赖于另一个团队吗？还是位于上游并必须将变更传达给下游的其他团队？
8. Label the relationship between the contexts. Is your team downstream and reliant on another team? Or is your team upstream and must communicate changes to other teams downstream from it?
9. 重复此过程，直到您掌握了有关您将要开发的景观的所有信息。
10. Rinse and repeat until you have captured all that you can about the landscape you will be developing in.

整个团队必须理解上下文图。把它挂在墙上，让所有团队成员都能看到，也让其他团队理解。这就是你的作战地图。它应该足够简单，以便所有人都能快速绘制，所以不要在UML图上花费太多时间。相反，要从整体上进行观察，当你开始整合时，放大接触点，然后再深入细节。

The whole team must understand the context map. Hang it on the wall for all the team to see and other teams to understand. This is your war map. It should be simple enough for all to draw quickly, so don’t spend too much time on UML diagrams. Instead, get a bird’s-eye view, and as you start to integrate, zoom in on touch points and then go into detail.

解决方案建模

Modeling a Solution

在开始建模解决方案并应用 DDD 原则之前，您需要确保您即将提供解决方案的产品满足以下标准：

Before starting to model a solution and applying the principles of DDD, you need to ensure the product you are about to provide a solution for meets the following criteria:

• 是一个复杂的问题，或者在子域中具有复杂性
• Is a complex problem or has complexity in a subdomain
• 对业务很重要并且对其抱有很高的期望
• Is important to the business and has high expectations of it
• 可以接触到领域专家
• Has accessibility to a domain expert
• 拥有一支积极进取、聪明睿智的团队
• Has a motivated and smart team

如果您的问题并不复杂，或者问题的一部分并不复杂，那么构建领域模型可能有些过度。当逻辑很少且仅涉及数据操作时，您应该采用更简单的方法来管理领域逻辑，例如事务脚本或 Active Record。这样可以避免一些成本更高的做法。

If you don’t have a complex problem or a portion of your problem is not complex, then building a domain model may be overkill. When there is little logic and merely data manipulation, you should follow a simpler method to manage domain logic, such as transaction script or active record. That way you can avoid some of the more costly practices.

如果产品对业务不重要，且预期不高，那么构建一个经得起时间考验的解决方案可能不值得。构建一个足够好的解决方案，并用于替换，而不是投资。您可以尝试使用现成的解决方案。如果您的问题比较普遍，那么可能已经有一个开源解决方案可以满足您的需求。

If the product is not important to the business and there are low expectations, it’s probably not worth the effort of building a solution to stand the test of time. Build good enough and build for replacement rather than investment. You can try and utilize an off-the-shelf solution. If your problem is generic there may well already be an open source solution out there that fits your needs.

如果你无法联系到领域专家，那么该领域的发现就无法实现。团队会围绕技术问题进行抽象，代码库中的语言也无法反映问题领域。上下文无法得到很好的定义，代码很快就会变得一团糟。

If you don’t have access to a domain expert, discoveries in the domain will not happen. The team will abstract around technical concerns, and the language in the codebase will not reflect the problem domain. Contexts will not be well defined, and quickly the code will evolve into a ball of mud.

如果您的团队没有动力或缺乏企业设计模式和原则的知识，那么最好采用更简单的模式来组织领域逻辑，这样就不会使开发工作过于复杂。

If your team is not motivated or lacks the knowledge of enterprise design patterns and principles, it may be best to favor a simpler pattern to organize domain logic so you don’t overcomplicate the development efforts.

重复

Rinse and Repeat

图 10.1直观地展示了应用 DDD 原则和实践的步骤。

Figure 10.1 visualizes the steps of applying the principles and practices of DDD.

模型在不断发展变化；如果不拥抱演进，就无法有效地利用 DDD 的实践和模式。您应该持续执行本节介绍的步骤。尽可能降低软件解决方案的复杂度是 DDD 的目标。所有原则和实践都是为了实现这一总体目标。作为开发人员，您的工作是随着迭代的变化不断挑战模型设计的有效性和简洁性，并不断改进模型设计以满足利益相关者的新行为。

A model is constantly evolving and changing; you cannot effectively utilize the practices and patterns of DDD without embracing evolution. You should perform the steps presented in this section constantly. Keeping the complexity of the software solution as low as possible is the goal of DDD. All the principles and practices are aimed at this overall goal. As a developer, it is your job to continuously challenge the effectiveness and simplicity of your model design as iterations change and evolve it to meet the new behaviors of the stakeholders.

一个有用的模型是通过数百次小的重构而形成的。模型不断地进行调整，通过小的变换来解锁新的发现。

A useful model is arrived at through hundreds of small refactorings. Adjustments to the model are made constantly, with discoveries being unlocked through small transformations.

在开发过程中，你可能会发现你对核心领域的假设会发生变化。业务部门可能会发现它错了。情况瞬息万变。当你意识到新的不变量会使你的设计失效时，你的边界也会随之改变。随着新功能的推出，你可能会发现歧义逐渐出现。如果出现这种情况，请拆分模型，并在特定上下文中明确定义这两个部分。

During development, you may find that your assumption on the core domain may change. The business may discover that it was wrong. Things change. Your boundaries will also change as you realize that new invariants invalidate your design. With new features, you may find that ambiguity creeps in. If it does, split the model and explicitly define the two parts in specific contexts.

记住，先从简单的开始，等真正需要的时候再逐步应用原则和实践。否则，你很可能会把一个简单的解决方案复杂化，从而解决一个简单的问题。

Remember to start simple, and move toward the principles and practices when you absolutely need them. Otherwise, you may very well overcomplicate a simple solution to a simple problem.

挑战你的假设

Challenge Your Assumptions

在每次迭代中，开发团队都必须挑战其假设，因为新增的功能可能意味着之前有用的模型不再适用。这项技能可以使您的软件保持灵活性，并随着产品的演进而发展，从而防止其变成“大泥球”（BBoM）。

During every iteration, the development team must challenge its assumptions because additional features may mean that a previously useful model is no longer fit for purpose. This skill enables your software to be flexible and evolve as the product evolves, thus preventing it from turning into a Big Ball of Mud (BBoM).

团队不应过于执着于基于第一次迭代需求的模型。后续迭代可能会发现模型无法满足新的功能需求。缺乏灵活性的团队很快就会发现代码对他们不利。当团队遵循测试驱动开发方法时，他们不会在系统正常运行时就止步不前。相反，他们会先通过测试，然后重构设计，使其更具表现力。这是测试驱动开发迄今为止最重要的方面，也应该应用于领域驱动设计 (DDD)。在获得知识后进行重构有助于生成更具表现力和启发性的模型。

A team should not become too attached to a model based on the requirements from a first iteration. Subsequent iterations may see the model become inadequate for the new feature requests. Teams that are inflexible about evolving will soon find that the code works against them. When teams follow a test-driven development methodology, they do not stop when the system is working. Instead, they make a test pass and then refactor their design to make it more expressive. This is by far the most important aspect of test-driven development and one that should be applied to DDD. Refactoring when knowledge is gained helps to produce a model that is more expressive and revealing.

建模是一项持续的活动

Modeling Is a Continuous Activity

建模活动可以在您需要时随时进行；它不是项目方法论中的一个步骤。您可以随时抽身与领域专家合作。如果您对所从事的领域有深入的了解，您可能会发现根本不需要建模。不要过于依赖您的软件；当业务模型发生变化时，要做好丢弃最佳代码的准备。每次迭代都会带来新的挑战。您需要确保不断改进和重塑您的模型，以满足新功能和新场景的需求。

The activity of modeling happens whenever you need it; it is not a step in a project methodology. You break out and collaborate with domain experts whenever it is required. If the area you are working on is well understood, you may find that you don’t need to model at all. Don’t get too attached to your software; be prepared to throw away your best code when the business model changes. With each iteration comes a new challenge. You need to ensure that you refine and reshape your model to meet the needs of new features and scenarios.

没有错误的模型

There Are No Wrong Models

不存在愚蠢的问题或愚蠢的想法。错误的模型有助于验证有用的模型，而创建模型的过程有助于学习。在复杂或核心的领域工作时产品，团队必须准备好以不同的方式看待事物，承担风险，并且不害怕将问题颠倒过来。

There is no such thing as a stupid question or a stupid idea. Wrong models help to validate useful ones, and the process of creating them aids learning. When working in a complex or core area of a product, teams must be prepared to look at things in a different way, take risks, and not be afraid of turning problems on their head.

对于复杂的核心领域，团队应该至少构建三个模型，这样才有机会产出一些有用的东西。那些失败次数不够多、想法也不够多的团队，很可能是因为他们还不够努力。在与领域专家深入交流时，团队不应该因为一有有用的想法就停止头脑风暴。一旦团队找到合适的思路，就应该擦掉白板，从不同的角度重新开始，尝试假设分析法。当团队与专家达到最佳状态时，应该一直保持这种状态，直到用尽所有想法。

For a complex core domain, a team should produce at least three models to give itself a chance at producing something useful. Teams that are not failing often enough and that are not producing many ideas are probably not trying hard enough. When deep in conversation with a domain expert, a team should not stop brainstorming at the first sign of something useful. Once the team gets to a good place, it should wipe the whiteboard and start again from a different angle and try the what-if route of investigation. When a team is in the zone with an expert, it should stay there until it exhausts all its ideas.

柔性代码助力发现

Supple Code Aids Discovery

在本书的第二、三和四部分中，您将学习组织代码库的模式，使其能够更有效地适应新需求。这些灵活的代码源于小型重构的迭代。不断重构以获得更深入的洞察，有助于实现灵活的设计和代码，从而能够促进变更并适应系统在每次迭代中添加的新功能。如果模型不灵活，它就毫无用处。Martin Fowler 在他的《分析模式：可重用对象模型》一书中提出了一个重要的建模原则： “设计模型时，应确保最频繁的模型修改只会导致最少类型的更改。”

In Parts II, III, and IV of this book, you will learn about patterns to organize your codebase to enable it to change more effectively with new requirements. This supple code is derived from iterations of small refactors. Constantly refactoring toward deeper insight helps lead to a supple design and flexible code that is able to facilitate change and adapt to new features of the system as they are added in each iteration. If a model is not supple, it is not useful. Martin Fowler states an important modeling principle in his book Analysis Patterns: Reusable Object Models: “Design a model so that the most frequent modification of the model causes changes to the least number of types.”

但是，要小心不要过早重构。在对领域有足够了解之前，不要进行重构，也不要专注于应用设计模式。推迟重构还可以揭示代码中哪些部分更改最频繁以及原因。有了这些了解，您就可以对代码库进行更明智的设计更改。

However, be careful of premature refactoring. Don’t refactor until you know enough about the domain, and don’t become preoccupied with applying design patterns. Delaying refactoring can also reveal which areas of the code change most often and why. With this knowledge, you can make more informed design changes to your codebase.

解决模糊性

Tackling Ambiguity

领域专家未提及或仅略微提及的内容往往是解锁模型中深层发现的关键。这些对领域专家来说可能并不重要的隐性概念应该明确化、命名化，并让开发团队充分理解。例如，假设一个电商网站禁止海外客户在购物车中添加超过 50 件商品。开发人员可以轻松实现此业务规则，如清单 10-1 所示。

It’s often the things the domain experts don’t say or barely hint at that are the key to unlocking deep discoveries within a model. These implicit concepts that may not appear important to domain experts should be made explicit, be named, and be fully understood by the development team. For example, consider an e-commerce site that prevents overseas customers from adding more than 50 of any one item to their basket. Developers can easily implement this business rule, as can be seen in Listing 10-1.

然而，在未来的几个月里，其他开发人员可能无法理解为什么存在这样的规则。相反，您应该理解规则存在的原因，并相应地命名代码部分。事实上，供应商强制执行这样的规则是为了防止网站充当批发商。有了这些知识，您可以将代码包装在一个类中，以表明对领域有更深入的了解和理解，从而使代码明确地揭示这条规则。此重构如清单 10-2 所示。

However, in future months, other developers may not understand why such a rule exists. Instead, you should understand why the rule exists and name the portion of code accordingly. As it transpires, suppliers enforce such a rule to prevent sites acting as wholesalers. With this knowledge, you can make the code explicitly reveal this rule by wrapping it in a class that indicates a deeper insight and understanding of the domain. This refactoring is seen in Listing 10-2.

开发人员应注意代码或领域专家语言中的歧义或不一致之处。在讨论领域模型时，还应特别注意其他团队成员的语言。务必通过与领域专家沟通，验证关于语言和模型细节的假设。大声验证，并确保语言和设计决策的一致性。如果领域专家没有提及，则不应出现在语言或代码库中。如果模型中的某个术语不再有意义或无用，请将其删除。保持语言简洁明了。领域专家应该对语言或模型中不恰当的术语或结构提出异议。

Developers should watch for ambiguity or inconsistency in code or in the language of a domain expert. You should also ensure that you pay particular attention to the language of other team members when discussing the domain model. Always validate assumptions about the language and details of the model by talking to domain experts. Validate aloud, and confirm your language and design decisions with linguistic consistency. If a domain expert doesn’t say it, it shouldn’t be in the language or codebase. If a term in the model no longer makes sense or is not useful, remove it. Keep your language small and focused. Domain experts should object to inadequate terms or structure in the language or model.

给事物起个名字

Give Things a Name

如果领域专家谈论某个概念，请明确说明。如果领域专家暗示了某个概念，请明确说明。如果您谈论的某个概念令领域专家感到困惑，则可能是您误解了他们所说的某些内容，您需要完善您的 UL。给它起个名字，如果想不出一个好名字，请将其推迟，并称之为蓝色政策，直到您能想到更有意义的名字。

If domain experts talk about it, make it explicit. If domain experts hint at a concept, make it explicit. If you talk about something that puzzles domain experts, maybe you have misunderstood something they have said and you need to work on your UL. Give things a name, and if you can’t think of a good name, defer it and call it the blue policy until you can think of something more meaningful.

领域模型应该传达业务意图。确保仔细命名类的所有方法和属性。尝试通过以下方式描述行为：不要把你的代码设计留给别人去解读。编写富有洞察力的代码，展现领域语言的丰富内涵，不仅能帮助你自己，也能帮助其他开发者。

A domain model should communicate the intent of the business. Ensure that you take care in naming all methods and properties of your classes. Try to describe the behaviors by involving the UL. Don’t leave your code design up to interpretation. Help yourself and other developers by writing code that is insightful, revealing the rich language of the domain.

不要解决所有问题

Don’t Solve All the Problems

所有问题都各有不同；有些问题很复杂，而且业务价值不大，因此没有必要浪费精力去寻找自动化解决方案。复杂的边缘情况并不总是需要自动化解决方案。人类可以通过例外情况进行管理。如果一个问题很复杂，并且构成了边缘情况，请与您的利益相关者和领域专家讨论自动化的价值。您的精力可以更好地投入到其他方面，而人类可能更适合处理这种例外情况。

All problems are not created equal; some are complex and are of little business value, so it makes no sense to waste effort in finding automated solutions for them. Complex edge cases do not always need automated solutions. Humans can manage by exception. If a problem is complex and forms an edge case, speak to your stakeholder and domain expert about the value of automating it. Your effort could be better served elsewhere, and a human might better handle this exception.

好就足够了

Good Is Good Enough

秉持 DDD 理念的团队更注重全局，并了解在何处投入最大精力。他们不会将相同的架构应用于解决方案的所有部分，也不会在价值不大的领域追求完美。他们会放弃独立且可运行的软件，转而追求不必要的优雅和华丽的装饰。

Teams that are aligned with the philosophy of DDD focus more on the bigger picture and understand where to put the most effort. They will not apply the same architecture to all parts of a solution, and they will not strive for perfection in areas of little value. They will trade isolated and working software for unnecessary elegance and gold plating.

只有核心领域由于其复杂性或重要性才需要优雅。这并不是说所有其他代码都应该写得很糟糕，而是应该被隔离，用边界定义，并暴露行为来支持核心领域。

Only the core domains need to be elegant due to complexity or importance. This is not to say that all other code should be poorly written, but it should be isolated, defined by a boundary, and expose behavior to support the core domain.

练习，练习，练习

Practice, Practice, Practice

软件开发是一个学习的过程，DDD 也是如此。如果你想擅长任何事情，你都需要练习、练习、再练习。如果你想成为一名优秀的开发人员而不是一名普通的开发人员，你需要对问题和解决方案表现出热情。要应用 DDD 的原则，你需要一个有动力且全心投入的团队——一个致力于学习其工艺和所针对的问题领域的团队。热情存在于我们每个人心中，如果你觉得 DDD 的实践很有价值，那么你就应该激励你的团队，成为一名传播者。热情是会传染的；如果你承诺花时间与领域专家一起更深入地理解某个领域，并能展示如何通过这种方式构建更具表现力的代码库，那么你的团队就会效仿。

Software development is a learning process, and so is DDD. If you want to be good at anything, you need to practice, practice, practice. If you want to be a great developer rather than a good one, you need to show passion for the problem and passion for the solution. To apply the principles of DDD, you need a driven and committed team—a team committed to learning about its craft and the problem domains it works in. Passion lies within all of us, and if you feel value in the practices of DDD, it is up to you to inspire your team and become an evangelist. Passion is contagious; if you commit to spend time with your domain experts to understand a domain at a deeper level and can show how this results in a more expressive codebase then your team will follow.

许多开发人员在棕地环境中工作时会感到厌烦，因为他们害怕不得不在其他开发人员的代码库上工作。在企业系统上工作时，你有时必须集成或在棕地环境中工作。优秀的开发人员擅长以安全且可维护的方式将新功能引入现有代码库。

Many developers are turned off when working in a brownfield environment because of fear of having to work on another developer’s codebase. When working on enterprise systems, you have to integrate or work on brownfield environments at some point. Great developers excel at introducing new features into an existing codebase in a safe and maintainable manner.

有界上下文是自治的

Bounded Contexts Are Autonomous

随着系统规模的扩大，依赖关系会变得越来越重要，这会带来负面影响。除非有充分的理由，否则您应该尽量避免大多数形式的耦合。代码耦合意味着一个团队可能会破坏另一个团队的代码，或者造成瓶颈，从而减慢新功能的交付速度。子系统之间的运行时耦合意味着一个系统如果没有另一个系统就无法运行。

As systems grow, dependencies become more significant in a negative way. You should strive to avoid most forms of coupling unless you have a very good reason. A coupling on code means that one team can break another team’s code or cause bottlenecks that slow down the delivery of new features. A runtime coupling between subsystems means that one system cannot function without the other.

如果设计松耦合的有界上下文，并限制依赖关系，那么每个有界上下文都可以独立开发。它的代码库可以进行演进，而不必担心破坏另一个有界上下文的行为，并且它的开发人员也不必等待其他有界上下文的开发人员完成工作或批准更改。

If you design loosely coupled bounded contexts that limit dependencies, each bounded context can be developed in isolation. Its codebase can be evolved without fear of breaking behavior in another bounded context, and its developers do not have to wait for developers in other bounded contexts to carry out some work or approve a change.

最终，当有界上下文松散耦合时，瓶颈可能会更少，并且更快、更有效地创造商业价值的可能性更高。

Ultimately, when bounded contexts are loosely coupled there are likely to be fewer bottlenecks and a higher probability that business value will get created faster and more efficiently.

在代码级别集成有界上下文的挑战

The Challenges of Integrating Bounded Contexts at the Code Level

您在第六章中了解到，有界上下文代表离散的业务功能，例如销售或运输。正如您在公司走廊里走动时会看到标识各个业务部分的标志一样，根据这些业务功能对软件系统进行划分是一种很好的做法。

You learned in Chapter 6 that bounded contexts represent discrete business capabilities, like sales or shipping. Just as you might walk through the corridors of the company you work for and see signs identifying each part of the business, it is good practice to partition your software systems in line with these business capabilities.

当你查看运输代码时，你关注的是业务的运输部分。如果销售部门的概念妨碍了你添加集成新运输供应商的新功能，那么这样做就没什么用了。事实上，修改运输代码可能会破坏销售功能。如果你听说过单一职责原则 (SRP)，你就会明白这一点。在领域驱动设计 (DDD) 中，你可以使用 SRP 将独立的业务功能隔离到单独的有界上下文中。不过，有时将有界上下文作为同一解决方案中的独立模块/项目存在也是可以接受的。

When you’re looking at the shipping code, you’re focused on the shipping part of the business. It’s not that helpful if you have concepts from the Sales Department getting in the way of adding a new feature that integrates a new shipping provider. In fact, making changes to the shipping code might break sales features. If you’ve heard of the Single Responsibility Principle (SRP), this will make perfect sense to you. In DDD, you can use the SRP to isolate separate business capabilities into separate bounded contexts. It is sometimes acceptable for your bounded contexts to live as separate modules/projects inside the same solution, though.

命名空间或项目保持有界上下文分离

Namespaces or Projects to Keep Bounded Contexts Separate

如果您选择将所有有界上下文都放在一个解决方案中，那么它们之间建立依赖关系的风险就会增加。如果两个有界上下文都使用了同一解决方案中另一个项目的代码，那么其中一个有界上下文可能会破坏另一个有界上下文，从而带来危险的风险。假设您在一个名为Eccommerce.Common或类似名称的共享项目中有一个名为User 的类：

If you do choose to locate all of your bounded contexts inside a single solution, there is an increased risk of creating dependencies between them. If two bounded contexts use code from another project inside the same solution, there is a dangerous risk of one bounded context breaking the other. Imagine that you have a User class in a shared project called Eccommerce.Common or similar:

public class User
{
    public String Name {get; set;}

    public String Id {get; set;}

    public void UpdateAddress(Address newAddress)
    {
        ...
    }
}

public class User
{
    public String Name {get; set;}

    public String Id {get; set;}

    public void UpdateAddress(Address newAddress)
    {
        ...
    }
}

如果运输限界上下文决定更改UpdateAddress()的实现，它可能会破坏销售限界上下文，因为销售限界上下文依赖于将旧地址持久化到特定位置或格式。此外，依赖共享代码的团队可能需要召开会议，商定如何更改以及何时能够更新代码以适应更改。团队之间的这种依赖关系可能会减慢项目进度，并引发不良的政治冲突。图 11.1可视化了一个包含多个独立限界上下文的解决方案。

If the Shipping bounded context decides to change the implementation of UpdateAddress(), it might break the Sales bounded context, which relied on the old address being persisted in a certain location or format. Also, the teams that rely on the shared code might need to have meetings to decide how it can be changed and when they will be able to update their code to accommodate the change. This kind of dependency between teams can slow down a project and introduce undesirable political scenarios. Figure 11.1 visualizes a single solution that contains multiple independent bounded contexts.

通过数据库集成

Integrating via the Database

另一个拖慢团队效率的常见依赖关系是数据库。例如，销售限界上下文的团队想要更新用户架构，但没有人确定这是否会破坏发货限界上下文或计费限界上下文中的代码。这可能会导致多个团队分心，无法处理业务优先级，而转而支持销售限界上下文的架构变更。团队之间的依赖关系并不理想，因为在团队同步时，新功能的交付速度会降低。

Another common dependency that slows down teams is the database. For example, the Sales bounded context’s team wants to update the User schema, but no one is sure if this will break code in the Shipping bounded context or the Billing bounded context. It’s likely that several teams will be distracted from working on business priorities to support the Sales bounded context’s schema change. A dependency between teams is undesirable because the rate of delivering new features is reduced while the teams synchronize.

如果您以前使用过数据库集成，您可能还会熟悉另一个常见问题：通过数据库集成的每个模型都有相似但又不同的领域概念。当多个模型使用相同的共享模式时，这种策略会变得很麻烦。例如，在家具领域，供应商可能销售大批量生产的家具和定制家具。这两个业务部分可能存在许多差异，并且可能是单独的限界上下文。但如果它们位于同一个代码库中，则每个模型的相似性很可能会导致所有类型的家具使用共享模式，如图11.2所示。

If you’ve used database integration in the past you may also be familiar with another common problem, where each model that integrates through the database has similar but distinct domain concepts. This strategy becomes painful when multiple models use the same shared schema. For example, in the domain of furniture, suppliers may sell mass-produced furniture and custom-made furniture. These two parts of the business are likely to have many differences and are likely to be separate bounded contexts. But if they reside in the same codebase, there is the likelihood that the similarities of each model will result in the use of a shared schema for all types of furniture, as shown in Figure 11.2.

最初，定制和量产限界上下文这两个模型可能很容易映射到共享模式上，但它们将来可能会出现分歧。当模型之间开始出现差异时，共享模式可能会包含与一个模型相关而与另一个模型无关的列。例如，定制家具模型可能需要一个新的制造优先级列，该列与量产限界上下文无关。然而，共享模式需要包含这个新字段。在某些情况下，每个模型甚至可能将列用于不同的目的。从多个限界上下文使用的共享模式创建报告可能容易出错、产生歧义或误导业务。

Initially, the two models of the custom-made and mass-produced bounded contexts may easily map onto the shared schema—but they are likely to diverge in the future. When differences between the models start to appear, the shared schema may have columns relevant to one model but not the other. For example, the custom-made furniture model may require a new manufacturing _ priority column that has no relevance to the mass-produced context. Yet the shared schema will need to include the new field. In some scenarios columns may even be used for different purposes by each model. Creating reports from a shared schema that is used by multiple bounded contexts can be error-prone, ambiguous, or misleading to the business.

从根本上讲，在不同语义的模型之间共享模式可能会违反 SRP，代价高昂。当代码库较小时，后果可能不那么严重。但随着系统的增长，由于每个有界上下文都指向不同的方向，这种痛苦可能会呈指数级增长。

Fundamentally, sharing a schema between models with different semantics can be an expensive violation of the SRP. When the codebase is small the consequences are less severe. But as the system grows, the pain is likely to increase exponentially as each bounded context pulls in different directions.

使用物理边界来强制清洁模型

Use Physical Boundaries to Enforce Clean Models

为了保持有界上下文的完整性并确保其自主性，最广泛使用的方法是使用无共享架构，其中每个有界上下文都有自己的代码库、数据存储和开发团队。如果正确实施，这种方法可以构建一个由垂直组件组成的系统，如图11.3所示。

To retain the integrity of your bounded contexts and ensure they are autonomous, the most widely used approach is to use a shared-nothing architecture, where each bounded context has its own codebases, datastores, and team of developers. When done correctly, this approach results in a system composed of verticals, as demonstrated in Figure 11.3.

当每个有界上下文在物理上相互隔离时，一个有界上下文中的开发人员就无法再调用另一个有界上下文中的方法，也无法将数据存储在共享模式中。由于存在明显的物理隔离，他们不得不费力地引入耦合。更可能的是，他们会因为额外的工作而放弃，或者在创建不必要的依赖之前被其他团队成员提醒。

When each bounded context is physically isolated, no longer can developers in one bounded context call methods on another, or store data in a shared schema. Since there is a distinct physical separation, they have to go out of their way to introduce coupling. More than likely, they will be put off by the extra effort or brought up to speed by another team member before they can create an unnecessary dependency.

一旦有界上下文被清晰地隔离，并显著降低耦合的可能性，其他外部因素就不太可能影响模型。例如，如果在一个有界上下文中添加或改进了一个概念，它将不会影响其他有界上下文中类似的概念。如果只有一个代码库，这些概念很容易受到影响。从根本上说，清晰的物理隔离使得每个有界上下文仅因内部原因而演进，从而形成一个不受影响的领域模型，并在短期和长期内更高效地交付业务价值。

Once bounded contexts are clearly isolated and the potential for coupling is significantly reduced, other external factors are unlikely to influence the model. For example, if a concept is added or refined in one bounded context it will not affect concepts that look similar in other bounded contexts, which could easily get caught up in the changes had there been a single codebase. Fundamentally, the clear physical separation allows each bounded context to evolve only for internal reasons, resulting in an uncompromised domain model and more efficient delivery of business value in the short and long term.

与遗留系统集成

Integrating with Legacy Systems

当您面临集成由遗留代码组成的有界上下文的限制时，可以使用多种模式来限制遗留代码对系统其他部分的影响。这些模式可以帮助您管理复杂性，并避免为了集成遗留组件而降低新代码的显式性。

When you are faced with the constraints of integrating bounded contexts that are comprised of legacy code, there are a number of patterns you can use to limit the impact of the legacy on other parts of the system. These patterns help you manage the complexity and save you from having to reduce the explicitness of your new code in order to integrate the legacy components.

气泡上下文

Bubble Context

对于不熟悉 DDD 但想要将其应用于遗留系统的团队，建议考虑使用气泡上下文。由于气泡上下文与现有代码库隔离，它们为创建和演进领域模型提供了一个干净的平台。请记住，当您完全控制领域模型，并能够在获得新的领域洞察后自由地对其进行频繁迭代时，DDD 的效果最佳。即使涉及遗留代码，气泡上下文也能促进频繁迭代。

Teams that are unfamiliar with DDD but want to begin applying it to a legacy system are advised to consider using a bubble context. Because bubble contexts are isolated from existing codebases, they provide a clean slate for creating and evolving a domain model. Remember, DDD works best when you have full control over the domain model and are free to frequently iterate on it as you gain new domain insights. A bubble context facilitates frequent iteration even when legacy code is involved.

为了使气泡上下文有效，气泡和遗留模型之间需要一个转换层。DDD 中的反腐败层 (ACL) 概念非常适合这一需求，如图11.4所示。

For bubble contexts to be effective, a translation layer is necessary between the bubble and the legacy model(s). The DDD concept of an anti-corruption layer (ACL) is ideal for this need, as shown in Figure 11.4.

在构建气泡上下文时，ACL 的设计和实现是一项关键活动。它需要将遗留系统的细节与气泡完全隔离，同时准确地将气泡中的查询和命令转换为遗留模型中的查询和命令。然后，它必须将遗留系统的响应映射到气泡所需的格式。因此，ACL 本身可能是一个复杂的组件，需要大量的持续投入。

Design and implementation of the ACL is a key activity when building a bubble context. It needs to keep details of the legacy system completely isolated from the bubble while at the same time accurately translating queries and commands from the bubble into queries and commands in the legacy model. It then has to map the response from the legacy into the format demanded by the bubble. Accordingly, the ACL itself can be a complex component that requires a lot of continued investment.

自治气泡上下文

Autonomous Bubble Context

如果你想与遗留代码集成，但又不想创建过于依赖遗留代码的气泡上下文，那么你可以使用自主气泡。而气泡上下文从遗留系统获取所有数据，自治气泡更加独立 - 拥有自己的数据存储，并且能够独立于遗留代码或其他有界上下文运行，如图11.5所示。

If you want to integrate with legacy code, but do not want to create a bubble context that is so dependent on the legacy code, you can instead use an autonomous bubble. Whereas a bubble context gets all its data from the legacy system, an autonomous bubble is more independent—having its own datastore(s) and being able to run in isolation of the legacy code or other bounded contexts, as shown in Figure 11.5.

有时，自治气泡上下文的独立性的关键在于与其他新旧上下文的异步通信。因此，ACL（同步 ACL）通常承担执行异步通信的角色，如图11.5所示。

Sometimes crucial to the autonomous bubble context’s independence is asynchronous communication with other new and legacy contexts. Consequently, the ACL—a synchronizing ACL—often takes on the role of carrying out the asynchronous communication, as also illustrated in Figure 11.5.

由于自治气泡上下文拥有自己的数据存储，因此无需更新旧代码库或架构。任何新数据都可以存储在自治气泡的数据存储中。在选择气泡还是自治气泡时，这一点非常重要。然而，异步同步的成本和复杂性可能会显著增加。

Since the autonomous bubble context has its own datastore it does not require updating legacy codebases or schemas. Any new data can be stored in the autonomous bubble’s datastore. This is an important characteristic to keep in mind when deciding between the bubble and the autonomous bubble. However, the costs and complexity of asynchronous synchronization can be significantly higher.

将遗留系统公开为服务

Exposing Legacy Systems as Services

当多个新上下文需要使用遗留系统时，为每个上下文创建专用 ACL 的成本可能会过高。您可以将遗留上下文公开为服务，这样新上下文就无需进行太多转换。一种常见且通常简单的方法是公开一个返回 JSON 的 HTTP API，如图11.6所示。这正式称为“开放主机”模式。

When a legacy system needs to be consumed by multiple new contexts the cost of creating a dedicated ACL for each context can be excessive. Instead, you can expose the legacy context as a service that requires less translation by the new contexts. A common, and often simple approach, is to expose an HTTP API that returns JSON, as shown in Figure 11.6. This is formally known as the Open Host pattern.

每个消费上下文仍然必须将来自旧上下文的响应转换为其自身的内部模型。然而，这种情况下转换的复杂性应该可以通过开放主机提供的 API 的简单性来减轻。

Each consuming context must still translate the response from the legacy context into its own internal model. However, the translation complexity in this scenario should be mitigated by the simplicity of the API provided by the open host.

虽然在有多个消费者的情况下，将遗留上下文公开为服务可能更高效，但两种气泡方法仍然值得考虑。将遗留上下文公开为服务有两个主要缺点：首先，需要对遗留上下文进行修改，而使用气泡方法则可能不需要修改。其次，公开一种易于多个消费者使用的格式可能具有挑战性。

While exposing legacy contexts as services can be more efficient when there are multiple consumers, both of the bubble approaches should still be considered. Two of the main drawbacks in exposing legacy contexts as services are that, first, modifications are required to the legacy context that may not be necessary with a bubble. Second, exposing a format that is easily consumable by multiple consumers may be challenging.

诚然，选择遗留系统集成策略可能会令人困惑。然而，通过三种方法的选择，您可以看到，在遗留系统上充分利用 DDD 的优势是完全可能的。

Admittedly, choosing a legacy integration strategy can be confusing. However, with three approaches to choose from, you can see that harnessing the benefits of DDD on legacy systems is definitely possible.

分布式有界上下文的集成策略

Integration Strategies for Distributed Bounded Contexts

分布式系统虽然有助于解决高可扩展性问题，但也存在一系列自身问题。幸运的是，您可以选择要面对哪些问题，因为有许多不同的集成策略。远程过程调用 (RPC) 和异步消息传递是常见的选项，涵盖了本章的大部分内容。然而，有时共享文件或数据库也是一个不错的选择。

Distributed systems, although helping to solve the problems of high scalability, come with their own set of problems. Luckily, you do have some choice about which set of problems you need to face, because there are a number of different integration strategies. Remote procedure call (RPC) and asynchronous messaging are prevalent options and encompass most of this chapter. However, sometimes sharing files or databases can be a good enough alternative.

分布式系统带来了非功能性需求：可扩展性、可用性和可靠性。可扩展性是指能够支持不断增加的负载（例如更多并发用户）的能力。可用性与应用程序在线、运行和支持用户的频率有关。另一个考虑因素是可靠性，它与系统处理错误的能力有关。您很快就会发现，这些需求通常与系统的耦合度和复杂度相权衡。

Distributed systems bring nonfunctional requirements to the table: scalability, availability, reliability. Scalability is the ability to be able to support increasing loads, such as more concurrent users. Availability is concerned with how often the application is online, running, and supporting its users. Another consideration is reliability, which is concerned with how well a system copes with errors. You’ll see shortly that these requirements are often traded off with the amount of coupling in a system and the level of complexity.

在集成有界上下文时，务必了解业务方的非功能性需求，以便选择能够以最少的工作量满足这些需求的集成策略。某些选项（例如消息传递）的实现需要更多工作量，但它们为实现高可扩展性和可靠性奠定了坚实的基础。另一方面，如果您对可扩展性要求不高，则可以使用数据库集成，在初期投入较少精力即可集成有界上下文。之后，您就可以更快地交付其他重要功能。

When integrating your bounded contexts, it’s important to get an idea from the business what its nonfunctional requirements are so that you can choose an integration strategy that lets you meet them with the least amount of effort. Some options, such as messaging, take more effort to implement, but they provide a solid foundation for achieving high scalability and reliability. On the other hand, if you don’t have such strong scalability requirements, you can integrate bounded contexts with a small initial effort using database integration. You can then get on with shipping other important features sooner.

遗憾的是，你不能直接问业务人员系统需要多大的可扩展性或多高的可靠性。试着给他们提供各种场景，并解释每种场景的成本。例如，你可以告诉他们，你可以保证 99.9999% 的可靠性，但成本是保证 99.99% 的三倍。

Unfortunately, you can’t just ask the business how scalable a system needs to be or how reliable it should be. Try to give them scenarios and explain the costs of each scenario. For example, you could tell them that you can guarantee 99.9999% reliability, but it will cost triple the amount of guaranteeing 99.99%.

数据库集成

Database Integration

集成有界上下文的一种可行方法是允许一个应用程序写入另一个应用程序读取的特定数据库位置。您可能希望在首次迭代的最小可行产品 (MVP) 或系统中非性能关键部分采用这种方法。

An accessible approach to integrating bounded contexts is letting one application write to a specific database location that another application reads from. It’s likely that you would want to employ this approach in first-iteration Minimum Viable Products (MVPs) or nonperformance critical parts of the system.

例如，当您下订单时，销售边界上下文可以将其添加到SQL 数据库中的销售表中。稍后，计费边界上下文会检查表中是否有新记录。如果发现有新记录，它会为每条记录处理付款。

As an example, when you place an order, the Sales bounded context could add it to the Sales table in a SQL database. Later on, the Billing bounded context would come along and verify whether any new records had been added to the table. If it found any, it would then process the payment for each of them.

实现此解决方案有几种可能性。最可能的例子是计费限界上下文以特定频率（例如每 5 分钟）轮询表，并通过更新同一行中的列（可能是paymentProcessed）来跟踪已处理的订单。您可以在图 11.7中看到此示例的直观表示。

Implementing this solution has a few possibilities. The most likely example involves the Billing bounded context polling the table at a certain frequency, such as every 5 minutes, and keeping track of which orders it has processed by updating a column in the same row—paymentProcessed perhaps. You can see a visual representation of this in Figure 11.7.

数据库集成也具有一些松散耦合的优势。由于两个系统都通过写入和读取数据库进行通信，因此每个系统的实现都可以自由更改，只要它与现有模式保持兼容。但是，由于两个系统耦合到同一个数据库，因此随着系统的增长，这种解决方案可能会开始对您造成损害。数据库锁只是您可能会遇到的一个棘手问题。随着系统的一部分将越来越多的订单添加到表中，然后由另一部分进行更新，这两个系统将争夺数据库资源。数据库很可能成为单点故障 (SPOF)，这意味着如果它停止运行，两个应用程序都会受到影响。某些数据库（例如 SQL Server）很难进行集群，因此您必须不断购买更大、更昂贵的硬件才能扩展。

Database integration also has some loose coupling benefits. Because both systems communicate through writing and reading to a database, the implementation of each system is free to change providing it maintains compatibility with the existing schema. However, the systems are coupled to the same database, so this style of solution can really start to hurt you as the system grows. Database locks are just one painful problem you might come up against. As increasingly more orders are added to the table by one part of the system and then updated by another, the two systems will be competing for database resources. The database will likely be a single point of failure (SPOF), meaning that if it grinds to a halt, both applications will suffer. Some databases, like SQL Server, are hard to cluster, so you have to keep buying bigger, more expensive hardware to scale.

另一个缺点是，数据库集成无法引导你找到处理故障的良好解决方案。如果销售限界上下文在保存订单之前崩溃了怎么办？订单会丢失吗？如果数据库宕机了怎么办？这是否意味着公司无法接受订单？这些都是使用数据库集成时你必须自己设计解决方案的大问题。

Another drawback is that database integration doesn’t guide you into a good solution for handling faults. What if the Sales bounded context crashes before saving an order? Is the order lost? What if the database goes down? Does that mean the company cannot take orders? These are big problems that you are left on your own to devise solutions for when using database integration.

平面文件集成

Flat File Integration

如果您的项目中没有使用数据库，那么仅仅为了集成两个组件而设置数据库可能会带来不必要的开销。这是一个平面文件集成可能就足够好的例子。一个组件将文件放在某个服务器上，而另一个应用程序稍后再获取它们，类似于数据库集成的方式。平面文件集成是一种比数据库集成更灵活的方法，但您必须更具创造力，这反过来意味着在重要的业务功能上需要付出更多努力并延长交付周期。在图 11.8中，您可以看到一种平面文件集成替代方案的可能实现，该方案可以替代图 11.8中的数据库集成解决方案。

If you aren’t using a database in your project, setting one up just to integrate two components can be unnecessary overhead. This is one example in which flat file integration may be good enough. One component puts files on a server somewhere, while another application picks them up later, in a similar way to database integration. Flat file integration is a more flexible approach than database integration, but you have to be more creative, which can in turn mean more effort and slower lead times on important business functionality. In Figure 11.8, you can see one possible implementation of a flat file integration alternative to the database integration solution in Figure 11.8.

平面文件集成保留了数据库集成的松耦合特性，避免了数据库锁定问题。遗憾的是，您必须付出更多努力才能弥补这一点。其中一个弥补方面涉及文件格式。由于没有模式或标准查询语言，您需要自行创建文件格式，并确保所有应用程序都能理解并正确使用。由于这需要更多手动操作，因此确实会增加出错的可能性，但这很大程度上取决于您的具体情况。

Flat file integration retains the loose coupling features of database integration without suffering from the database locking problem. Unfortunately, you have to work harder to compensate for this. One area of compensation involves the file format. Because there is no schema or standard query language, you are responsible for creating your own file format and ensuring that all applications understand it and use it correctly. Because this is more manual work, it does increase the possibility for error, although a lot depends on your circumstances.

由于平面文件集成是一种自行解决的解决方案，因此没有可扩展性或可靠性方面的指导原则。它完全取决于您选择的技术以及您如何实现它们。如果您确实需要一种可扩展的方法，那么投入所有这些精力可能会造成巨大的浪费，并且巨大的风险。接下来讨论的 RPC 是一种常见的替代方案，它在可扩展性和可靠性特性方面相对知名。

Because flat file integration is a do-it-yourself solution, there are no scalability or reliability guidelines. It’s completely dependent on the choice of technologies you use and how you implement them. If you do need an approach that scales, going to all that effort can be a massive waste and a massive risk. RPC, discussed next, is a common alternative that is a relatively well known quantity in terms of scalability and reliability characteristics.

RPC

RPC

想象一下，如果您可以保持单体应用几乎完全相同，同时又能获得分布式系统的可扩展性优势，那会是怎样一番景象。这正是使用 RPC 的动力所在。使用 RPC 时，任何方法调用都可能通过网络调用其他服务；除非您查看具体实现，否则无法判断。您能知道运行以下代码片段会产生多少次网络调用吗？

Imagine if you could keep your monolithic almost identical but get the scalability benefits of a distributed system. This is the motivating force behind the use of RPC. When using RPC, any method invocation could call another service across the network; it’s not possible to tell unless you look at the implementation. Can you tell how many network calls would occur if you ran the following code snippet?

var order = salesBoundedContext.CreateOrder(orderRequest);
var paymentStatus = billingBoundedContext.ProcessPaymentFor(order);
if (paymentStatus.IsSuccessful)
{
    shippingBoundedContext.ArrangeShippingFor(order);
}

var order = salesBoundedContext.CreateOrder(orderRequest);
var paymentStatus = billingBoundedContext.ProcessPaymentFor(order);
if (paymentStatus.IsSuccessful)
{
    shippingBoundedContext.ArrangeShippingFor(order);
}

由于您不知道被调用的任何方法内部发生了什么，因此无法判断前面的代码片段中发生了多少次网络调用。这些调用可能是内存逻辑，也可能是对执行该逻辑的其他应用程序的网络调用。RPC 的支持者认为这一特性具有巨大的优势，因为它是一种侵入性最小的解决方案。在某些情况下，RPC 可能是最佳选择。

It’s impossible to tell how many network calls occur in the previous code snippet because you don’t know what happens inside any of the methods that are called. There could be in-memory logic, or there could be network calls to other applications that carry out the logic. Proponents of RPC see this trait as a huge benefit because it is a minimally invasive solution. In some situations, RPC can be the best choice.

选择 RPC 时，您拥有很大的自由度，因为 RPC 本身是一个可以通过多种方式实现的概念。如果您与大量使用 RPC 的公司交流，您会发现他们使用大多数类型的 Web 服务，例如简单对象访问协议 (SOAP)、表述性状态转移 (REST)、可扩展标记语言 (XML)——使用各种不同的技术，例如 Windows Communication Foundation (WCF)。RPC 往往比平面文件集成更容易，因为大多数编程社区都有框架可以帮你处理大量的基础设施。

When choosing RPC, you have a lot of freedom, because RPC itself is a concept that you can implement in a variety of ways. If you were to talk to enough companies using RPC, you would find examples using most kinds of web service—Simple Object Access Protocol (SOAP), REpresentational State Transfer (REST), eXtensible Markup Language (XML)—using a variety of different technologies, such as Windows Communication Foundation (WCF). RPC tends to be easier than flat file integration because most programming communities have frameworks that deal with a lot of the infrastructure for you.

许多分布式系统新手倾向于使用 RPC，因为他们现有的大部分代码都可以复用。这无疑是选择 RPC 的一个有力理由，但同时也存在一些缺点。在后面的部分（“分布式系统中 DDD 的挑战”）中，您将详细了解为什么 RPC 的吸引力在实现可扩展性和可靠性方面存在一些深层次的缺陷。正因如此，异步、响应式消息传递解决方案才显得尤为重要。

Many distributed systems novices are tempted to use RPC because most of their existing code can be reused. This is a compelling case for choosing RPC, but it is also a drawback. In a later section (“The Challenges of DDD with Distributed Systems”), you learn in some detail why RPC’s appeal has some deep flaws for achieving scalability and reliability. That is why there is a need for asynchronous, reactive messaging solutions.

消息传递

Messaging

简而言之，网络是不可靠的。即使是像 Netflix 和 Amazon 这样的巨头公司，也会遭遇网络问题，导致系统宕机（http://www.thewhir.com/web-hosting-news/netflix-outage-caused-by-ec2-downtime-reports）。响应式解决方案试图通过使用异步消息传递模式进行通信来提高可靠性，从而拥抱故障。这意味着，当消息失败时，系统可以检测到并稍后重试（例如将其存储在队列中）或采取其他措施。

Quite simply, networks are unreliable. Even the biggest companies like Netflix and Amazon suffer from network problems that result in system outages (http://www.thewhir.com/web-hosting-news/netflix-outage-caused-by-ec2-downtime-reports). Reactive solutions try to embrace failure by increasing reliability using asynchronous messaging patterns for communication. This means that when a message fails, there is a way for the system to detect this and try it again later (such as storing it in a queue) or take a different course of action.

不幸的是，使用消息传递通常意味着，与 RPC 不同，你的代码看起来截然不同。当你查看 RPC 代码时，看不到任何网络方面的痕迹；而当你查看许多消息传递解决方案时，很明显代码是异步的，并且可能涉及网络。不仅如此，消息传递系统的整体设计和架构也截然不同，团队面临着令人望而生畏的学习曲线的挑战。幸运的是，你将在本章和下一章中学习消息传递，因为除了 RPC 之外，消息传递是构建分布式 DDD 系统的另一个常用选项。特别是，你将了解到消息传递的异步特性也为提高可扩展性提供了平台。

Unfortunately, using messaging usually means that, unlike RPC, your code looks drastically different. When you look at RPC code, there’s no hint of the network; when you look at many messaging solutions, it’s clear that code is asynchronous, and there’s probably a network involved. Not only that, but the entire design and architecture of messaging systems are significantly different, and teams are challenged with an intimidating learning curve. Fortunately, you will learn about messaging in this chapter and the next because, along with RPC, it is the other common option used for building distributed DDD systems. In particular, you will learn that the asynchronous nature of messaging also provides the platform for improved scalability.

休息

REST

如果您想要消息传递解决方案的可扩展性和可靠性优势，但又想使用超文本传输​​协议 (HTTP) 而不是消息传递框架，不妨尝试 REST。REST 会将您的端点建模为富超媒体资源，并充分利用 HTTP 的诸多优势，例如其动词和标头。​​然后，您可以使用 REST 在 HTTP 之上构建事件驱动系统，从而获得消息传递系统的诸多优势，有时还能减少问题。

If you want the scalability and reliability benefits of messaging solutions, but you want to use Hypertext Transport Protocol (HTTP) instead of messaging frameworks, try REST. REST involves modeling your endpoints as hypermedia-rich resources and using many of the benefits of HTTP, such as its verbs and headers. You can then build event-driven systems on top of HTTP with REST to get many of the benefits of a messaging system, and sometimes fewer of the problems.

REST 也是一个实用的工具，可以将您的系统公开为应用程序编程接口 (API)，供其他应用程序集成。在本章学习分布式系统概念之后，您将在第 13 章“通过 HTTP 使用 RPC 和 REST 进行集成”中了解有关 REST 集成的更多信息。

REST is also a useful tool for exposing your system as an application programming interface (API) for other applications to integrate with. After learning about distributed systems concepts in this chapter, you will learn more about integrating with REST in Chapter 13, “Integrating via HTTP with RPC and REST.”

RPC 的问题

The Problem with RPC

当需要将应用程序从单一代码库扩展到多个较小的子系统时，您可能会想用 HTTP 调用替换类的实现。这样，旧逻辑就会转移到新的子系统，也就是此 HTTP 调用的目标。这样做很诱人，因为您可以将负载分散到两台机器上，而无需更改太多代码。实际上，代码看起来是一样的，如前面的代码片段（如下所示）所示：

When the time comes to scale your application from a single codebase to a number of smaller subsystems, you might be tempted to replace the implementation of a class with an HTTP call. The old logic then moves to a new subsystem, which is the target of this HTTP call. It’s tempting because you can spread the load across two machines without having to change much code. In fact, the code looks the same, as the previous code snippet (repeated below) demonstrates:

var order = salesBoundedContext.CreateOrder(orderRequest);
var paymentStatus = billingBoundedContext.ProcessPaymentFor(order);
if (paymentStatus.IsSuccessful)
{
    shippingBoundedContext.ArrangeShippingFor(order);
}

var order = salesBoundedContext.CreateOrder(orderRequest);
var paymentStatus = billingBoundedContext.ProcessPaymentFor(order);
if (paymentStatus.IsSuccessful)
{
    shippingBoundedContext.ArrangeShippingFor(order);
}

每个方法调用可以完全在内存中处理，也可以通过 HTTP 调用另一个执行相应逻辑的服务。请记住，这就是 RPC 的目标：使网络通信透明化。如图 11.9所示，是一个使用 RPC 下单的电商系统的示例。

Each method call can be processed entirely in memory or can make an HTTP call to another service that carries out the logic. Remember that this is the goal of RPC: to make network communication transparent. Have a look at Figure 11.9 to see an example of an e-commerce system using RPC to place an order.

虽然 RPC 感觉上很好地运用了面向对象编程和封装，但它也存在一些分布式系统社区多年来熟知的重大缺陷。这些缺陷很容易抵消您与领域专家频繁协作、精心构建领域模型所付出的辛勤努力。为了避免您遭受 RPC 带来的困扰，我们将先了解其固有问题，然后再向您展示尝试解决其缺点的替代方法。之后，您将能够自行决定 RPC 或消息传递是否是您项目的最佳选择。

Although RPC feels like good use of object-oriented programming and encapsulation, it has some significant flaws that the distributed systems community has known for years. These flaws can easily negate the determined effort you spent frequently collaborating with domain experts and finely crafting your domain models. To save you suffering from the pain caused by RPC, you will now learn its inherent problems before being shown alternative approaches that attempt to address its drawbacks. You will then be able to decide for yourself if RPC or messaging is the best choice for the projects you work on.

分布式事务损害可扩展性和可靠性

Distributed Transactions Hurt Scalability and Reliability

事务是维护数据一致性的最佳实践。然而，在构建分布式系统时，由于涉及网络通信，事务的成本很高。因此，诸如过多的长期数据库锁定或部分故障等原因可能会对可扩展性和可靠性产生负面影响。因此，在构建分布式系统时，您应该仔细考虑分布式事务以及 RPC。

Transactions are a best practice for maintaining data consistency. Unfortunately, when building distributed systems, transactions carry a high cost because of the involvement of network communication. As a result, scalability and reliability can be negatively impacted for reasons such as excessive long-held database locks or partial failures. Therefore, you should carefully consider distributed transactions, as well as RPC, when building distributed systems.

分布式事务的一个典型示例是预订包含酒店和航班的假期，您的系统存储酒店信息，但航班信息由外部系统处理。当您下订单时，数据库中的酒店房间信息会被锁定。该锁定会保留一段时间，直到航班预订完成。由于通过互联网向航空公司发出 HTTP 调用平均需要几秒钟，因此数据库锁定和连接的数量会不断增长。一旦数据库达到临界点，它们就会崩溃，拒绝新的连接，甚至出现更糟糕的情况。随着系统规模的扩大，这个问题的严重性只会增加，这意味着收入损失的可能性也会增加。

A typical example of a distributed transaction is booking a holiday that consists of a hotel and a flight, where your system stores hotels but flights are handled by an external system. When you place an order, a lock is put on the hotel room in your database. The lock is then held for a while until the flight is booked. Because it takes on average a few seconds to make the HTTP call over the Internet to the flight company, the number of database locks and connections grows. Once you reach a tipping point with databases, they tend to fall over and reject new connections or worse. As your system starts to scale up, the severity of this issue only increases, meaning that opportunities for revenue loss increase.

使用分布式事务时的另一个担忧是部分可用性。如果您锁定了酒店数据库记录，而航班提供商却离线了，该怎么办？在分布式事务中，您就会遇到故障，这意味着事务会中止或回滚。如果没有同时预订酒店和航班的特定业务需求，那么由于可避免的技术错误，这又会造成收入损失。

Another concern when using distributed transactions is partial availability. What if you lock a hotel database record and find the flight provider is offline? In a distributed transaction, you have a failure, meaning the transaction aborts or rolls back. If there’s no specific business requirement for hotels and flights to be booked at the same time, this is again a loss of revenue due to avoidable technical errors.

事件驱动的反应式 DDD

Event-Driven Reactive DDD

20 多年来，分布式系统专家们早已意识到同步 RPC 的局限性，因此在很多情况下更倾向于采用异步的事件驱动型消息传递解决方案 ( http://armstrongonsoftware.blogspot.co.uk/2008/05/road-we-didnt-go-down.html )。在深入探讨这种方法为何更具优势之前，我们将先了解如何使用它来解决上一个 RPC 示例中的弹性和可扩展性问题。

For more than 20 years, distributed systems experts have known about the limitations of synchronous RPC and instead preferred asynchronous, event-driven messaging solutions in many situations (http://armstrongonsoftware.blogspot.co.uk/2008/05/road-we-didnt-go-down.html). Before delving into the fundamentals of why this approach can be more beneficial, you will see how to use it to remedy the resilience and scalability issues of the previous RPC example.

在本节中，您将学习如何选择良好的集成策略，从而带来巨大的可扩展性和可靠性优势，并最终对业务产生积极的影响。您将看到一种基于响应式编程原则的替代解决方案。（http://www.reactivemanifesto.org/）——一种用异步消息取代 RPC 的理念。图 11.10展示了图 11.9中 RPC 实现的替代反应式消息传递的设计。

In this section, you learn how choosing a good integration strategy can have massive scalability and reliability benefits that make a positive business impact. What you are about to see is an alternative solution using the principles of reactive programming (http://www.reactivemanifesto.org/)—a philosophy that replaces RPC with asynchronous messages. Figure 11.10 shows the design of a reactive messaging alternative to the RPC implementation shown in Figure 11.9.

将有界上下文视为 SOA 服务

View Your Bounded Contexts as SOA Services

如果说响应式编程是一套旨在实现松散耦合软件组件的底层技术指南，而 SOA 是一个促进松散耦合业务功能的高层概念，那么这种组合似乎是创建面向业务、可扩展且具有弹性的分布式系统的完美选择。目前缺失的环节是如何将这些优势与 DDD 结合起来。一个答案是将有界上下文视为 SOA 服务，以便将高层有界上下文映射到低层事件驱动的软件组件上。现在，您就有机会获得 SOA 的业务一致性优势以及响应式编程的可扩展性/弹性优势。下一章将提供本节介绍的概念的完整实现示例。

If reactive programming is a set of low-level technical guidelines that lead to loosely coupled software components, and SOA is a high-level concept that facilitates loosely coupled business capabilities, then the combination appears perfect for creating business-oriented, scalable, resilient distributed systems. The missing link so far is how to combine these benefits with DDD. One answer is to view your bounded contexts as SOA services so that you can map high-level bounded contexts onto low-level, event-driven software components. Now you have the potential for the business alignment benefits of SOA and scalability/resiliency benefits of reactive programming. Full examples of implementing the concepts introduced in this section are provided in the next chapter.

将有界上下文分解为业务组件

Decompose Bounded Contexts into Business Components

在有界上下文中，你可能承担多项职责。例如，在运输有界上下文中，可能存在处理优先订单和标准订单的逻辑。通过将每项主要职责隔离为一个组件，你会发现自己与业务部门的对话更加清晰，并且能够享受到 DDD 的所有其他好处，这些好处你已经看到过，它们都是通过把隐式职责显式化而产生的。此外，通过两个独立的模块，每个模块承担一项职责，你的代码库将更加清晰。这些类型的组件称为业务组件。你可以在图 11.11中看到可能存在于运输有界上下文中的不同业务组件的示例。

Inside a bounded context you may have a number of responsibilities. In a Shipping bounded context, for example, there may be logic to deal with priority orders and standard orders. By isolating each major responsibility as a component, you’ll find yourself having clearer conversations with the business and all the other benefits of DDD that you’ve already seen arise from making the implicit explicit. Additionally, you’ll have increased clarity in your codebase by having two separate modules, each with a single responsibility. These types of components are called business components. You can see examples in Figure 11.11 of the different business components that might exist inside a Shipping bounded context.

不要一开始就费力地识别业务组件。相反，要随着时间的推移逐渐将它们区分开来。通常，你会在与领域专家的沟通中发现一些模式，或者在代码中反复检查相同条件的模式。这些都是你深入挖掘并重构模型的触发因素。

Don’t try too hard to identify business components up front. Instead, tease them apart over time. Often you will notice patterns in communication with domain experts, or patterns in code that repeatedly check for the same condition. These are your triggers to dig deeper and restructure your model(s).

一个重要的规则是，SOA 服务只是逻辑容器；一旦您分解了业务组件中的有界上下文，服务本身就没有剩余的工件或行为。正如服务需要解耦且不共享依赖关系一样，同样的规则也适用于业务组件——即使与同一有界上下文内的其他业务组件之间也不存在共享依赖关系。然而，业务组件本身也只是由组件组成的逻辑容器。

One important rule is that SOA services are just logical containers; once you’ve decomposed a bounded context in business components, the service itself has no remaining artifacts or behavior. Just as services need to be decoupled and share no dependencies, the same rule applies to business components—no shared dependencies, even with other business components inside the same bounded context. However, business components themselves are also just logical containers that are composed of components.

将业务组件分解为组件

Decompose Business Components into Components

业务组件可能负责处理多个事件，因此您应该将它们分解以获得更多好处。例如，在“发货”限界上下文中，“优先发货”业务组件可能处理“OrderPlaced”和“OrderCancelled”消息。通过让这些组件处理这些消息，可以实现更高效的处理。通过由不同的软件组件处理的消息，可以更轻松地根据业务需求更好地调整硬件资源。企业可能希望快速响应OrderPlaced事件，以便尽快安排发货。但是，由于OrderCancelled消息数量很少，因此快速响应这些消息对他们来说并不那么重要。因此，如果将“优先发货”业务组件分解为“安排发货”组件和“取消发货”组件，企业可以将“安排发货”组件放在速度极快的裸机服务器上，同时让“取消发货”组件在小型虚拟化服务器上​​缓慢运行。图 11.12显示了如何将“发货”限界上下文内的业务组件分解为组件的示例。

Business components may be responsible for handling multiple events, so you should break them down for further benefits. For example, in the Shipping bounded context, the Priority Shipping business component may handle OrderPlaced and OrderCancelled messages. By having these messages processed by different software components, it’s easier to better align hardware resources with the needs of the business. The business may want a rapid response to the OrderPlaced event so that shipping is arranged as soon as possible. However, it’s not so important for them to respond as quickly to OrderCancelled messages because there are so few of them. Therefore, if the Priority Shipping business component is broken down into the Arrange Shipping component and the Cancel Shipping component, the business can put the Arrange Shipping component on blazing-fast, bare-metal servers while allowing the Cancel Shipping component to slowly grind away on a small virtualized server. Figure 11.12 shows an example of how the business components inside a Shipping bounded context could be broken down into components.

最终，组件的优势在于，企业可以明智地将资金投入到系统中可能带来收入增长的特定部分。然而，硬件经济性只是其中一项优势。另一个优势是，可以根据业务优先级和性能需求将组件部署到不同的网络上。因此，一些需要高性能的有界上下文可以拥有极快的服务器和专用的高带宽网络。通常，使用细粒度的组件可以更灵活地满足业务需求。

Ultimately, the benefit of components is that the business can spend money intelligently on the specific parts of the system that are likely to result in increased revenue. Hardware economics is just one of the benefits, though. Another is the possibility of locating components on different networks in line with business priority and performance needs. So, some bounded contexts that need high performance can have blazing-fast servers and dedicated high-bandwidth networks. In general, by having granular components you have more flexibility to align with the needs of the business.

您可能已经意识到，组件是部署的单位。图 11.13直观地展示了如何在具有不同资源级别（CPU、RAM、SSD 等）的不同机器或云实例上部署电子商务应用程序中的不同组件。

As you may have gathered, components are the unit of deployment. Figure 11.13 visualizes this by showing how you can deploy different components in an e-commerce application on different machines or cloud instances with varying resource levels (CPU, RAM, SSDs, and so on).

虽然有界上下文和业务组件之间差异很大，以至于它们之间的 RPC 调用或共享数据库可能会导致弹性或可扩展性问题，但组件之间却不会出现同样的问题。组件之间通常协作非常紧密；因此，拥有像数据库这样的共享依赖关系可以提高内聚性，而不一定会导致问题。不过，如果您认为在特定情况下使用消息传递能带来最佳的平衡，您仍然可以自由地在组件之间使用消息传递。

Whereas bounded contexts and business components are distinct enough that having RPC calls between them or a shared database can lead to resilience or scalability problems, the same is not true for components. Components often work together very closely; therefore, having shared dependencies like a database increases cohesion without necessarily causing problems. You are still free to use messaging between components if you feel it gives the best trade off in a given situation, though.

您可以使用图 11.14来帮助您记住共享依赖关系可能仅存在于业务组件内部，而不存在于它们之间。

You can use Figure 11.14 to help you remember that shared dependencies may exist only inside a business component, not between them.

与软件开发中的许多其他术语一样，“组件”这个术语含义模糊且含糊不清。在本章中，您可以看到有业务组件和组件（不带前缀）。遗憾的是，社区尚未真正为本章中提到的“组件”提出一个标准名称。Udi Dahan 将它们称为自治组件（http://www.drdobbs.com/web-development/business-and-autonomous-components-in-so/192200219 ）。其他人根据基于组件的开发定义（http://en.wikipedia.org/wiki/Component-based_software_engineering ），将它们称为组件（如本章中所示） 。然而，现在其他人开始将它们称为微服务，如下一节所示。

The term component, like many others in software development, is vague and ambiguous. In this chapter, you can see that there are business components and components (without a prefix). Unfortunately, the community hasn’t really come up with a standard name for what this chapter refers to as just components. Udi Dahan refers to them as autonomous components (http://www.drdobbs.com/web-development/business-and-autonomous-components-in-so/192200219). Others refer to them as components (as in this chapter) based on the component-based development definition (http://en.wikipedia.org/wiki/Component-based _ software _ engineering). Yet others are now starting to refer to them as micro services, as shown in the next section.

微服务架构的进一步发展

Going Even Further with Micro Service Architecture

Netflix 采用了一种细粒度的 SOA 方法，其他公司现在也开始以微服务架构 (MSA) 的名义应用这种方法。MSA 最大的优势在于其上市时间和实验优势。所以，如果你正在为一家企业工作如果您喜欢对其系统进行大量更改并衡量每个更改的影响以推动新功能和现有功能的发展，那么您应该考虑 MSA。

Netflix uses a fine-grained approach to SOA that other companies are now starting to apply under the name Micro Service Architecture (MSA). Some of the biggest reported benefits of MSA are its time-to-market and experimentation advantages. So if you find yourself working for a business that likes to make lots of changes to its system and measure the impact of every change to drive the evolution of new and existing features, you should consider MSA.

到目前为止，遵循本章中的指导，您将接近 MSA，其中每个组件类似于一个微服务。但是，MSA 有一些明显的区别。每个微服务必须完全自治，以便可以添加、删除或修改业务功能而不会影响任何其他微服务。因此，每个微服务都应该有自己的宕机数据库，并且几乎肯定会通过发布/订阅使用事件进行通信，因为命令和 RPC 会引入耦合。至少，这是 Fred George（最早开始谈论 MSA 的人之一）在其 2012 年 Oredev 演讲（https://www.youtube.com/watch?v=q3q6ZsjZ_f0）中描述的 MSA 风格。微服务的另一个特性是它们的代码量应该少于一千行，尽管这肯定存在争议，但许多人都认同这一点。

Following the guidance in this chapter so far will get you close to an MSA, where each component is akin to a micro service. However, MSA has some distinct differences. Each micro service must be completely autonomous so that the business feature can be added, removed, or modified without impacting any other micro service. Therefore, each micro service should have its down database and, almost certainly, communicate using events via publish/subscribe because commands and RPC introduce coupling. At least, this is the style of MSA described by Fred George, one of the first people to start talking about MSA, in his Oredev 2012 talk (https://www.youtube.com/watch?v=q3q6ZsjZ_f0). Another feature of micro services that many people agree on, although it is certainly contentious, is that they should be less than a thousand lines of code.

有关 MSA 的更多信息，Martin Fowler 的介绍性博客系列是一个很好的起点（http://martinfowler.com/articles/microservices.html）。

For more information on MSA, Martin Fowler’s introductory blog series is a useful place to begin (http://martinfowler.com/articles/microservices.html).

消息总线

Message Bus

如果系统中只有一个中心化组件负责传输所有消息，那么一旦它停止工作，整个系统就会崩溃。同样令人担忧的是，这个单一组件这会使系统的各个部分更难根据业务需求进行扩展。您可以使用消息总线（一种分布式系统，在每个发送或接收消息的组件上运行代理）来解决这些问题，从而避免集中式单点故障。消息总线是所有这些组件协同工作的集合，如图12.1所示。

If one centralized component in the system was responsible for transmitting all the messages, the whole system would collapse if it stopped working. Equally as concerning, this single component would make it more difficult for individual parts of the system to be scaled according to business need. You can solve these problems by using a message bus—a distributed system that has agents running on every component that sends or receives messages—avoiding the need for a centralized single point of failure. A message bus is all of these pieces collectively working together, as shown in Figure 12.1.

使用消息总线可以将有界上下文完全解耦。每个有界上下文（更具体地说，每个组件）仅连接到总线。如果一个组件离线，其他连接的组件都不会受到影响。

Using a message bus allows bounded contexts to be completely decoupled from each other. Each bounded context—more specifically, each component—is connected only to the bus. If a component goes offline, none of the other connected components is affected.

可靠的消息传递

Reliable Messaging

如果无法保证消息一定能到达，那么从一个限界上下文向另一个限界上下文发送消息的成本可能会很高——如果由于消息在系统中某个地方丢失而导致客户从信用卡中扣款却无法发货，他们会非常不高兴。这就是需要可靠消息传递的原因。遗憾的是，几乎不可能保证一条消息始终只传递一次。如果消息已发送但未收到确认，则可以再次发送。但是，如果收到了消息但未收到确认怎么办？当然，系统会错误地假设未收到第一条消息，从而再次发送同一条消息。

Sending messages from one of your bounded contexts to another could be costly if there were no guarantees the message would ever get there—customers aren’t very happy when you charge their credit card but fail to ship their product because a message got lost in your system somewhere. This is the reason that reliable messaging is needed. Unfortunately, it’s almost impossible to guarantee that a message will always be delivered only once. If a message is sent and no acknowledgement is received, it can be sent again. But what if the message was received but the acknowledgement wasn’t? Of course, the same message will be sent again under the incorrect assumption that the first was not received.

由于可靠传递的挑战，存在各种可靠的消息传递模式，每种模式都有自己的挑战和权衡，包括：如前所述，至少一次、最多一次和仅一次传递。

Because of the challenges with reliable delivery, there are a variety of reliable messaging patterns, each with its own challenges and trade-offs, including: at-least-once, at-most-once, and only-once delivery as previously alluded to.

随着你对消息传递系统的了解，你会发现“至少一次”通常是首选方案，即使它仍然存在消息可能被处理两次的风险。为了避免这种情况可能造成的问题，例如对一个订单收取两次重要客户的费用，本章将介绍如何将“至少一次”投递与幂等消息相结合。

As you learn about messaging systems, you’ll see that at-least-once is normally the preferred option, even though it does still carry the risk that a message may be handled twice. To avoid problems that this may cause, like charging valuable customers twice for a single order, this chapter shows how to combine at-least-once-delivery with idempotent messages.

至少一次投递涉及重试失败或未收到接收方确认（看似失败）的消息。重试失败或未收到确认的消息的实际流程依赖于一种称为“存储转发”的模式。

At-least-once delivery involves retrying messages that failed or no acknowledgement from the receiver was received (appearing to fail). The actual plumbing for retrying failed or unacknowledged messages relies on a pattern known as store-and-forward.

存储转发

Store-and-Forward

消息发送后，可能无法到达接收者。网络、硬件或编程错误都可能导致这种情况。存储转发模式通过在发送消息之前存储消息来解决许多此类问题。如果消息到达接收者并得到确认，则本地副本将被删除。但是，如果消息未到达接收者，则会再次尝试发送。在本章中，您将看到消息传递框架如何处理大部分复杂性。通过允许您设置有关重试消息的频率以及两次尝试之间等待的时间的规则。

When a message is sent, it might not reach the recipient. The network could fail, hardware could fail, or programming errors could manifest. The store-and-forward pattern remedies many such problems by storing the message before it is sent. If the message reaches the recipient and is acknowledged, the local copy is deleted. However, if the message does not reach the recipient, it is tried again. You’ll see in this chapter how messaging frameworks deal with most of the complexity by allowing you to set up rules about how often messages should be retried and how long to wait between attempts.

大多数消息传递框架使用队列来存储消息。因此，当服务 A 向服务 B 发送消息时，该消息最终会进入服务 B 的队列。当服务 B 处理该消息时，它会将其从队列中移除。但是，如果服务 B 未完成消息处理，该消息也会被放回队列并稍后重试。

Most messaging frameworks use queues to store messages. So when Service A sends Service B a message, the message ends up on Service B’s queue. When Service B processes the message, it takes it off the queue. However, if Service B doesn’t complete processing the message, it also gets put back on the queue and retried later.

命令和事件

Commands and Events

有时你会想要发送指定需要发生某事的消息，例如第 11 章中的PlaceOrder。这类消息称为命令。使用命令时，发送者和接收者之间存在逻辑耦合，因为发送者知道接收者应该如何处理消息。命令只能由一个接收者处理，这非常不灵活。或者，事件发出某些事情发生的信号，例如OrderCreated。事件比命令更松散地耦合，因为发送者不知道接收者将如何处理消息。事实上，发送者不知道谁处理消息。这是因为事件基于发布/订阅模式。

Sometimes you will want to send messages that specify something needs to happen, such as PlaceOrder from Chapter 11. These kinds of messages are known as commands. With commands there is a logical coupling between the sender and the receiver because the sender knows how the receiver should handle the message. Commands are only handled by one receiver, which is quite inflexible. Alternatively, events signal that something happened, such as OrderCreated. Events are more loosely coupled than commands because the sender doesn’t know how the receiver will handle the message. In fact, the sender doesn’t know who handles the messages. This is because events are based on the publish/subscribe pattern.

发布/订阅提供的松散耦合意味着事件通常比命令更受欢迎。事件的一个显著优势是，您可以在不更改现有代码的情况下添加新的订阅者。这使得企业能够添加全新的有界上下文，而无需更改任何现有代码或减慢其他开发团队的速度。在上一章的电子商务示例中，只需订阅OrderCreated事件即可将新的 Marketing 有界上下文添加到流程中，如图 12.2所示。

The looser coupling offered by publish/subscribe means events are often preferable to commands. One significant advantage of events is that you can add new subscribers without changing existing code. This allows the business to add a completely new bounded context without changing any existing code or slowing down other development teams. In the e-commerce example from the previous chapter, the new Marketing bounded context could be added to the flow just by subscribing to the OrderCreated event, as illustrated in Figure 12.2.

您可能会在网上遇到一些关于命令和事件命名的争论。您可以自由选择，但最常见的意见是将命令命名为您希望发生的指令（例如 PlaceOrder、ChangeAddress、RefundAccount ），并将事件命名为描述已发生事件的过去时（例如OrderCreated、MovedAddress、AccountRefunded ）。

You might run into some debate online about naming commands and events. You’re free to make your own choices, but the most common opinion is to name commands as instructions that you want to happen—PlaceOrder, ChangeAddress, RefundAccount—and to name events in the past tense describing what has happened—OrderCreated, MovedAddress, AccountRefunded.

最终一致性

Eventual Consistency

如果您构建的消息传递系统中的每个有界上下文都有自己的数据库，那么您最终会遇到在使用大事务的系统中不常见的情况。一个常见的例子是没有付款确认的订单。在使用事务的系统中，这种状态可能无法实现，因为创建订单是处理付款的同一原子操作的一部分。如果付款失败，则不会创建任何订单。相反，消息传递解决方案允许这种状态，因为它们消除了大事务并实现了最终一致性。

If you’re building messaging systems in which each bounded context has its own database, you will end up in situations that aren’t common in systems that use big transactions. An order without payment confirmation is a common example. In a system that uses transactions, this state might not be possible because creating an order is part of the same atomic operation that processes payments. Should the payment fail, no order will be created. Conversely, messaging solutions would allow this state because they remove big transactions and are eventually consistent.

最终一致性系统最重要的方面之一是用户体验管理。在一致性系统中，用户会等到整个交易完成。此时，他们知道订单已创建、付款已处理、发货已安排。然而，正如第 11 章所述，大型交易的扩展性并不总是很好。在最终一致性系统中，用户通常会立即收到订单意向的确认，并在付款和发货处理完毕并安排好后再收到电子邮件确认，这看起来可能会降低用户体验。

One of the most important aspects of eventually consistent systems is managing the user experience. In consistent systems, users wait until the whole transaction completes. At which point, they know the order was created, the payment was processed, and the shipping was arranged. However, you know from Chapter 11 that big transactions do not always scale very well. In eventually consistent systems, users often get an immediate confirmation that the intent to place an order has been received, with a further e-mail confirmation later when payment and shipping have been processed and arranged, which can appear to be a degradation of user experience.

您可以将最终一致性发挥到极致，转向业务，思考在最终一致状态下应该发生什么。有时，您可以挖掘隐藏的业务策略或机会。如需更详细的阅读，强烈推荐 Udi Dahan 的博客文章“竞争条件不存在”( http://www.udidahan.com/2010/08/31/race-conditions-dont-exist/ )。

You can use eventual consistency as a positive by turning to the business and asking what should happen in eventually consistent states. Sometimes you can unlock hidden business policies or opportunities. For more detailed reading, Udi Dahan’s “Race Conditions Don’t Exist” blog post is highly recommended (http://www.udidahan.com/2010/08/31/race-conditions-dont-exist/).

设计系统

Designing the System

在打开 IDE 之前，先将要构建的内容可视化会很有帮助。当一些概念比较新时，这一点尤其有用。了解它们如何组合在一起，可以让你更好地理解实际构建的内容。本章中的电商应用程序设计需要三个设计步骤。第一步是创建一个容器图，展示应用程序分组、技术选择和通信协议。第二步是创建一个组件图，展示有界上下文之间的逻辑流。但第一步也是最重要的一步是从领域开始。

Before you crack open an IDE, it can be helpful to visualize what you are trying to build. This can be particularly useful when some of the concepts are new. Seeing how they fit together allows you to better understand what you’re actually building as you go along. Designing the e-commerce application in this chapter requires three design steps. One step is to create a containers diagram showing application groupings, technology choices, and communication protocols. Another step is to create a component diagram showing the flow of logic between bounded contexts. But the first and most important step is to start with the domain.

领域驱动设计

Domain-Driven Design

正如您在本书第一部分所学到的，构建软件最重要的方面无疑是理解构建它的原因，这样您才能为系统的目标用户提供价值。因此，在设计系统时，强烈建议您花费大量时间与领域专家一起构建一种通用语言 (UL)，并将隐含的领域概念明确化。一些领域驱动设计 (DDD) 从业者建议您首先识别领域中发生的重要事件。这被称为事件风暴 (Event Storming )，它可以与消息传递应用程序高度协同 ( http://ziobrando.blogspot.co.uk/2013/11/introducing-event-storming.html )。

As you’ve learned in the first part of this book, arguably the most important aspect to building software is to understand why you are building it so that you can provide value to people you are building the system for. So when designing a system, it is highly recommended that you spend a significant amount of time with domain experts building up a ubiquitous language (UL) and making implicit domain concepts explicit. Several DDD practitioners recommend that you start by identifying important events that occur in the domain. This is known as Event Storming, and it can be highly synergistic with messaging applications (http://ziobrando.blogspot.co.uk/2013/11/introducing-event-storming.html).

领域事件

当你构建通过共享命令和事件进行集成的有界上下文时，你就有绝佳的机会将领域中发生的重要事件与软件系统中发生的事件进行映射。许多知名的 DDD 从业者都使用此模式来表达在构建的消息传递系统中明确地体现领域概念。要做到这一点，首先需要识别现实世界领域中发生的重要事件。这些事件被称为领域事件。

When you’re building bounded contexts that integrate by sharing commands and events, you have an excellent opportunity to map important events that occur in the domain with the events occurring in the software system. This pattern is used by a number of well-known DDD practitioners to express domain concepts explicitly in the messaging systems they build. To do this yourself, you first need to identify important events that occur in the real-world domain. These are known as domain events.

在本书第一部分“领域驱动设计的原则与实践”中，你了解了多种捕获领域知识的方法，包括事件。这通常发生在你与领域专家进行知识研讨、非正式聚会，甚至团队午餐等场合。在上一章中，我们介绍了一些在现实世界领域中发生的事件，即使没有软件系统，这些事件仍然会发生。其中一些事件包括“下订单”、“付款已接受”和“安排发货”。在构建消息传递系统时，如果你额外努力寻找类似的领域事件，将会获得丰厚的回报。

In Part I of this book, “The Principles and Practices of Domain-Driven Design,” you saw a number of ways to capture domain knowledge, including events. This normally occurs when you are with domain experts during knowledge-crunching sessions, informal get-togethers, or even team lunches and such. In the previous chapter, a number of events occurred in the real-world domain and would still occur even if there was no software system. Some of them are Order Placed, Payment Accepted, and Shipping Arranged. When you are building a messaging system, it can pay dividends if you make an extra effort to look for domain events like these.

捕获领域事件后，它们将成为 UL 的一部分，您可以开始将它们拼凑在一起，了解它们如何组合成完整的业务用例。存储和共享这些知识的一个好方法是在组件图上可视化事件序列。

Once captured, your domain events form part of the UL, and you can start to piece them together to learn how they combine to form full business use cases. An excellent way to store and share this knowledge is by visualizing the sequence of events on a component diagram.

组件图

在编写代码之前，先勾勒出高层逻辑，这样您就可以更高效、更正确地构建组件，因为您了解自己在做什么。这正是组件图大有裨益的地方。开始创建组件图的最佳时机是与领域专家进行知识研讨时。您可以一起绘制基本草图，仅使用方框和线条来传达领域事件和流程。当您开始编码时，您已经对需要构建的内容以及需要在系统中建模的 UL 中的术语有了大致的了解。

By sketching out high-level logic before you write code, you are in a better position to build the component efficiently and properly because you understand what you are doing. This is where a component diagram provides a lot of benefit. A useful time to start creating component diagrams is during knowledge-crunching sessions with domain experts. You can produce basic sketches together using just boxes and lines to communicate domain events and processes. When you then sit down to start coding, you already have an idea of what you need to build and terminology from the UL that needs to be modeled in your system.

组件图没有正式的结构；它们传达的是特定组件之间的逻辑流程或交互。不应过于深入地描述技术选择，也不应过于详细地展示类或方法名称。图 12.3中展示了一个示例，它展示了即将构建的电子商务应用程序中有界上下文之间的消息流。

Component diagrams have no formal structure; they communicate the flow of logic or interaction between certain components. You shouldn’t go too high level and show technology choices, and you shouldn’t go too detailed and show class or method names. You can see an example of this in Figure 12.3, which shows the flow of messages between bounded contexts in the e-commerce application you’re going to build.

您可以根据需要绘制任意数量的组件图。在本例中，有一个组件图用于描述订单下单场景的流程。您可以先遵循以下惯例：每个高级用例对应一个组件图，并评估其效果。

You can have as many component diagrams as you feel are necessary. In this example, there is one component diagram that communicates the flow of the order placement scenario. You could start by following this convention: having one component diagram per high-level use case and assessing how that works for you.

容器图

Containers Diagrams

一旦你与领域专家共事一段时间，并开始理解该领域，那么在某个时候，你就需要开始构建系统了。此时，你需要将业务需求映射到一个能够为其提供价值的分布式软件系统上。创建容器图是一种可以帮助你平衡功能性领域需求和非功能性技术需求的技术。

Once you have spent time with domain experts and you are starting to understand the domain, at some point you’ll need to start building the system. It’s at this time you need to map the requirements of the business onto a working, distributed software system that provides them value. One technique that can help you balance the functional domain requirements with the nonfunctional technical requirements is to create containers diagrams.

应用程序的不同部分如何相互通信？如何确保系统能够提供必要的容错能力和可扩展性？如何确保团队中的每个人都了解正在构建的内容，以免犯下大错？对于大多数软件项目来说，这些都是重要的问题，而容器图可以帮助您解答这些问题。这种类型的图展示了系统不同部分如何分组、如何通信以及主要的技术选择。

How do the different parts of an application talk to each other? How can you be confident the system will provide the necessary fault tolerance and scalability? How can you make sure everyone on the team understands what is being built so they don’t do something completely wrong? These are important questions for most software projects, and a containers diagram helps you answer them. This type of diagram shows how different parts of the system are grouped, how different parts of the system communicate, and what the major technology choices are.

请看图 12.4，这是本章重点介绍的电子商务应用程序的容器图。

Take a look at Figure 12.4, which is a containers diagram of the e-commerce application that is the focus of this chapter.

系统设计中需要注意的一些关键点如下：

Some of the key points to take note of in the system design follow:

• 有界上下文之间的内部通信使用消息传递。
• Internal communication between bounded contexts uses messaging.
• 与外部支付提供商的不可靠通信通过消息传递网关进行包装，以增加可靠性。
• Unreliable communication with the external payment provider is wrapped with a messaging gateway to add reliability.
• 每个有界上下文能够使用不同的技术，包括数据库技术的选择。
• Each bounded context is able to use different technologies, including choice of database technology.
• 有界上下文不共享数据库或其他依赖项。
• Bounded contexts do not share databases or other dependencies.
• 该网站使用通过浏览器的 AJAX 请求提供的 HTTP 应用程序编程接口 (API) 从有界上下文中检索信息。
• The website retrieves information from bounded contexts using the HTTP application programming interfaces (APIs) they provide via AJAX requests from the browser.

从图 12.4中的容器图可以看出，通过使用消息传递解决了容错和可扩展性问题。您还可以看到，每个有界上下文都提供了一个 API，浏览器可以使用该 API 获取数据，并通过 HTTP 显示在网页上。该图还验证了一些技术选择。例如，由于每个有界上下文都使用 C#，因此您可以使用单一的消息传递技术 (NServiceBus)，从而简化集成。但是，如果您的要求指出可以使用不同的语言和平台构建新的有界上下文，该设计可能会让您更深入地考虑选择 NServiceBus 或任何消息传递技术，而更喜欢 REST（您将在下一章中使用它构建系统），因为它具有更友好的跨平台集成。

From the containers diagram in Figure 12.4, you can see that fault tolerance and scalability have been addressed by using messaging. You can also see that each bounded context provides an API that the browser can use to get data to show on web pages using HTTP. The diagram also validates some technology choices. For instance, because each bounded context is using C#, you can use a single messaging technology (NServiceBus) that makes integration easier. However, if your requirements stated that new bounded contexts may be built using different languages and platforms, the design might make you think deeper about choosing NServiceBus or any messaging technology and instead prefer REST (which you will build a system with in the next chapter) for its friendlier cross-platform integration.

根据上一章的讨论，有些设计决策可能比较合理。其他一些决策你可能觉得违反直觉，或者只是不同意。这完全没问题。读完本章后，你将涵盖此应用程序中的所有设计决策。你可以自行决定是否同意。

Some of the design decisions may make sense following the discussion from the previous chapter. Other decisions you may find counterintuitive or just disagree with. And that’s completely fine. By the end of this chapter, all the design decisions in this application will have been covered. You can then decide for yourself if you agree.

从 Web 应用程序发送命令

Sending Commands from a Web Application

下单始于客户在网站上结账。这是图 12.3所示组件图中的第一步。要启动消息传递系统，您需要创建一个 Web 应用程序，该应用程序可以通过发送代表客户意愿的PlaceOrder命令来启动此流程。本示例将使用一个简单的 MCV 4 网站，该网站只有一个可以下单的页面。图 12.5展示了它的外观。

Placing an order begins with customers checking out on the website. This is the first step in the component diagram shown in Figure 12.3. To get started with the messaging system, you need to create a web application that can initiate this process by sending a PlaceOrder command representing the customer’s wishes. For this example, a simple MCV 4 website with just a single page where orders can be placed will be used. Figure 12.5 shows what this will look like.

正如你所见，UI 的外观设计并不是本章的重点。然而，将数据推送到消息系统却是重点。

As you can clearly see, the appearance of the UI is not a significant part of this chapter. However, pushing data into the messaging system is.

创建使用 NServiceBus 发送消息的 Web 应用程序

Creating a Web Application to Send Messages with NServiceBus

在创建 Web 应用程序之前，您需要在 Visual Studio 中创建一个名为DDDesign的空白解决方案。该解决方案最终将托管整个系统。图 12.6演示了创建空 Visual Studio 解决方案的过程。

Before creating the web application, you need to create a blank solution inside Visual Studio called DDDesign. This solution will eventually host the entire system. Figure 12.6 illustrates the process of creating an empty Visual Studio solution.

在 NServiceBus 应用中，消息是限界上下文之间的契约。消息必须能够被发布它们的限界上下文和消费它们的限界上下文访问。因此，一个好的惯例是，每个限界上下文都有一个项目，只包含它发布的消息。其他限界上下文可以引用这个项目来访问消息。

In an NServiceBus application, messages are the contract between bounded contexts. The messages must be accessible to the bounded context that publishes them and the bounded contexts that consume them. So a good convention is for each bounded context to have a project that contains just the messages it publishes. Other bounded contexts can reference this project to access the messages.

定义消息

图 12.3中的组件图显示，第一步是从网站向销售限界上下文发送PlaceOrder命令。这使得PlaceOrder命令成为属于销售边界上下文的消息。因此，您需要创建的第一个项目是销售边界上下文的消息项目。您可以通过在刚刚创建的DDDesign解决方案中添加一个名为Sales.Messages的新 C# 类库来实现。

The component diagram in Figure 12.3 shows that the first step is a PlaceOrder command being sent from the website to the Sales bounded context. This makes the PlaceOrder command a message that belongs to the Sales bounded context. Therefore, the first project you need to create is the Sales bounded context’s messages project. You can do that by adding a new C# class library called Sales.Messages to the DDDesign solution you just created.

在新创建的Sales.Messages项目中，现在可以添加PlaceOrder命令，该命令代表用户想要购买某些产品的真实场景。在本例中，在项目根目录中添加一个名为Commands的文件夹，并添加一个名为PlaceOrder的类，其内容如下：

Inside your newly created Sales.Messages project, you can now add the PlaceOrder command that represents the real-world scenario of a user indicating he would like to buy certain products. For this example, add a folder called Commands to the root of the project and a class called PlaceOrder with the following content:

namespace Sales.Messages.Commands
{
    public class PlaceOrder
    {
        public string UserId { get; set; }

        public string[] ProductIds { get; set; }

        public string ShippingTypeId { get; set;}

        public DateTime TimeStamp { get; set; }
    }
}

namespace Sales.Messages.Commands
{
    public class PlaceOrder
    {
        public string UserId { get; set; }

        public string[] ProductIds { get; set; }

        public string ShippingTypeId { get; set;}

        public DateTime TimeStamp { get; set; }
    }
}

现在，您可以创建可以发送PlaceOrder命令的网站了。在同一个解决方案中，您需要添加一个新的 ASP.NET MVC 4 项目，选择空模板和 Razor 视图引擎。将该项目命名为DDDesign.Web 。这些步骤如图 12.7和图 12.8所示。

Now you’re in a position to create the website that can send the PlaceOrder command. Inside the same solution, you need to add a new ASP.NET MVC 4 project, choosing the empty template and the Razor View Engine. Name this project DDDesign.Web. These steps are illustrated in Figure 12.7 and Figure 12.8.

现在，您需要在解决方案资源管理器中右键单击DDDesign.Web项目图标，并选择“添加引用”。然后选择“解决方案项目”选项。最后，您可以添加对Sales.Messages项目的引用，如图 12.9所示。

Now you need to right-click on the DDDesign.Web project icon in the Solution Explorer and choose Add Reference. Then select the Solution Projects option. Finally, you can add a reference to the Sales.Messages project, as illustrated in Figure 12.9.

网站要发送命令，需要内部运行 NServiceBus。您可以使用 Visual Studio 中的 NuGet 包管理器控制台添加对 NServiceBus 的引用来实现这一点。只需运行Install-Package命令，如图12.10和以下代码片段所示：

For the website to send commands, it needs NServiceBus running inside it. You can make that happen by adding a reference to NServiceBus using the NuGet package manager console inside Visual Studio. Just run the Install-Package command, as demonstrated in Figure 12.10 and the following snippet:

Install-Package NServiceBus –ProjectName DDDesign.Web -Version 4.3.3

Install-Package NServiceBus –ProjectName DDDesign.Web -Version 4.3.3

配置仅发送的 NServiceBus 客户端

现在您已经引用了 NServiceBus 依赖项，您需要配置 NServiceBus 使其在 Web 应用程序内部实际运行。NServiceBus 使用自托管选项使此操作变得非常容易，您可以在Global.asax.cs中配置该选项，如清单 12-1 所示。

Now that you have referenced the NServiceBus dependencies, you need to configure NServiceBus to actually run inside the web application. NServiceBus makes this quite easy with the self-hosting option, which you can configure in Global.asax.cs, as shown in Listing 12-1.

如清单 12-1 所示，不需要太多配置。然而，这几行代码中有一些关键细节。首先，配置的最后一行SendOnly()告诉 NServiceBus，此应用程序仅发送消息，不接收消息。如果你回顾容器图，就会发现这完全符合设计。在 NServiceBus 的命名法中，仅发送消息的应用程序被称为客户端。

As Listing 12-1 shows, there isn’t too much configuration needed. However, among those few lines are some key details. First, the last line of configuration, SendOnly(), tells NServiceBus that this application only sends messages and does not receive them. If you look back at the containers diagram, you can see that this is exactly as per the design. In NServiceBus nomenclature, a send-only application is known as a client.

DefiningCommandsAs ()方法用于指定一个约定，让 NServiceBus 知道解决方案中的哪些类是命令。在本例中，您可以看到它是任何命名空间包含单词Commands 的类。如果您回顾一下定义PlaceOrder命令的位置，您会发现它位于名为Commands的文件夹中，因此将按照此约定进行选择。您不必强制使用此约定；您可以使用任何您喜欢的约定，甚至可以使用 XML 配置。

The DefiningCommandsAs() method is used to specify a convention that lets NServiceBus know which classes in the solution are commands. In this example, you can see it is any class whose namespace contains the word Commands. If you look back to where you defined the PlaceOrder command, you’ll see that it is inside a folder called Commands and therefore will be picked up by this convention. You don’t have to use this convention; you can use any convention you like, and you can even use XML configuration instead if you prefer.

另一个关键的配置是UseTransport<Msmq>()这行。正如本章开头所述，消息总线通常将消息存储在队列中以实现容错，以便在出现错误时可以重试消息。这行配置指示 NServiceBus 使用 Microsoft 的 MSMQ。您也可以使用 RabbitMQ 或 ActiveMQ。

The other key piece of configuration is the line UseTransport<Msmq>(). As mentioned at the start of the chapter, a message bus usually stores messages in a queue for fault tolerance so that messages can be retried if there is an error. This line of configuration instructs NServiceBus to use Microsoft’s MSMQ. You can also use RabbitMQ or ActiveMQ.

发送命令

Sending Commands

现在总线已配置完毕并可用，您可以使用它来发送命令。在本例中，我们通过添加一个OrdersController 控制器来实现，网页会将用户的订单回发到该控制器。然后， OrdersController 控制器会使用您之前配置的总线发送PlaceOrder命令。要添加OrdersController 控制器，请在DDDesign.Web项目中右键单击Controllers文件夹，然后选择“添加控制器”。输入OrdersController作为控制器名称，然后单击“添加”。图 12.11演示了此过程。

Now that the bus is configured and available, you can use it to send commands. In this example, that is accomplished by adding an OrdersController that a web page posts the user’s order back to. The OrdersController then sends the PlaceOrder command using the bus you configured earlier. To add the OrdersController, right-click on the Controllers folder inside the DDDesign.Web project and choose Add Controller. Type in OrdersController as the controller name and click Add. Figure 12.11 illustrates this.

创建OrdersController后，您可以使用清单 12-2 中的代码替换文件的全部内容。

Once you’ve created the OrdersController, you can replace the entire contents of the file with the code in Listing 12-2.

此示例特意简化，以突出消息传递的方面。无论如何，使用 NServiceBus 发送消息相对简单。只需创建消息实例，并将其与收件人名称一起传递给Bus.Send()，该函数会异步发送消息。发送命令时，请确保指定收件人，因为命令仅在一个位置处理。稍后您将看到，发布事件时无需指定收件人。记住这一点很有用。

This example is intentionally quite simplistic to accentuate the messaging aspects. Sending messages with NServiceBus is relatively straightforward anyway. You just create an instance of your message and, together with the name of the recipient, pass it to Bus.Send(), which sends the message asynchronously. When sending commands, make sure you specify the recipient because commands are only handled in a single place. Later you will see that specifying the recipients is not necessary when publishing events. This is a useful distinction to remember.

您还可以在本例中看到最终一致性的体现。在订单被系统各部分成功处理之前，用户会立即收到响应。这一点在第11章中特别强调过，因为它能够在用例中的任何步骤失败时提供容错能力。如果您还记得的话，它还允许网站独立于系统的其他部分进行扩展，因为它不像远程过程调用 (RPC) 解决方案那样等待其他部分完成处理。如果您对这些优势还不甚了解，可以简要回顾一下上一章的内容。

You can also see in this case an example of eventual consistency. The user gets an immediate response before the order has successfully been processed by each part of the system. This was specifically highlighted in Chapter 11 because it provides fault tolerance should any of the steps in the use case fail. If you remember, it also allows the website to be scaled independently of other parts of the system because it does not wait for them to do processing as would be the case with remote procedure call (RPC) solutions. It would be useful to briefly revisit the last chapter if these benefits aren’t clear.

在发送PlaceOrder命令之前，只剩下一件事：需要添加一个带有表单的网页来输入订单详细信息。要创建该网页，首先需要在DDDesign.Web项目的Views文件夹中添加一个名为Orders的文件夹。在新创建的Orders文件夹中，添加一个名为Index.cshtml的文件。然后删除Index.cshtml的全部内容，并将其替换为清单 12-3 的内容。如果操作正确，解决方案结构应类似于图 12.12。

Only one thing now remains before PlaceOrder commands are sent: a web page with a form to enter the order details needs to be added. To create that web page, you first need to add a folder called Orders inside the Views folder in the DDDesign.Web project. Inside the newly created Orders folder, add a file called Index.cshtml. Then delete the entire contents of Index.cshtml and replace it with the contents of Listing 12-3. If you have done this correctly, your solution structure should resemble Figure 12.12.

清单 12-3 只是一个简单的 HTML 表单，用于下订单。图 12.5展示了该页面的渲染效果。

Listing 12-3 is just a simple HTML form that allows the order to be placed. Figure 12.5 shows how this page appears when rendered.

处理命令和发布事件

Handling Commands and Publishing Events

现在，Web 应用程序已经包含一个允许客户创建订单的页面和一个将使用提供的详细信息在总线上发送PlaceOrder命令的控制器，您需要实际处理PlaceOrder命令。回顾图 12.3中的图表，您可以看到PlaceOrder命令由销售边界上下文处理，该上下文处理该命令并发布OrderCreated事件。因此，在本节中，您将在销售边界上下文中创建一个包含此逻辑的组件。

Now that the web application has a page that allows customers to create orders and a controller that will use the supplied details to send a PlaceOrder command on the bus, you need to actually handle PlaceOrder commands. Looking back to the diagram in Figure 12.3, you can see that PlaceOrder commands are handled by the Sales bounded context, which processes the command and publishes an OrderCreated event. So in this section, you’ll create a component in the Sales bounded context that contains this logic.

Install-Package NServiceBus.Host -ProjectName
Sales.Orders.OrderCreated -Version 4.3.3

Install-Package NServiceBus.Host -ProjectName
Sales.Orders.OrderCreated -Version 4.3.3

配置解决方案以进行测试和调试

Configuring the Solution for Testing and Debugging

在继续发布事件之前，这是一个很好的机会来测试到目前为止一切是否正常，并且你对消息传递的工作原理有一个基本的了解。NServiceBus 让这一切变得简单在本地计算机上调试分布式系统。您需要做的就是配置每个项目以使其正确启动，具体步骤如下：

Before moving on to publishing events, this is a good opportunity to test that everything is working so far and that you have a basic understanding of how messaging works. NServiceBus makes it easy to debug a distributed system on your local machine. All you need to do is configure each project to start up appropriately, as detailed in the following steps:

1. 在解决方案资源管理器中右键单击解决方案文件，然后选择“属性”（图 12.13）。
2. Right-click on the solution file in the Solution Explorer and select Properties (Figure 12.13).
3. 选择“通用属性”下方的“启动项目”选项。
4. Select the Startup Project option beneath Common Properties.
5. 激活多个启动项目单选按钮。
6. Activate the Multiple Startup Projects radio button.
7. 将DDDesign.Web和Sales.Orders.OrderCreated项目的操作设置为开始。
8. Set the Action as Start for the DDDesign.Web and Sales.Orders.OrderCreated projects.
9. 将DDDesign.Web移至列表底部。
10. Move DDDesign.Web to the bottom of the list.
11. 检查您的屏幕是否如图12.14所示。
12. Check that your screen looks like Figure 12.14.
13. 单击“确定”。
14. Click OK.

此时，您可以按 F5 开始调试应用程序。Web 应用程序将在浏览器中加载，并且销售边界上下文将在控制台中加载。如果仔细查看控制台，您会发现 NServiceBus 处理了很多繁琐的工作，例如创建所有必要的队列，如图12.15所示。

At this point, you can press F5 to start debugging the application. The web application loads in the browser, and the Sales bounded context loads in a console. If you look carefully at the console, you can see that NServiceBus takes care of lots of the hard work, such as creating all the necessary queues, as shown in Figure 12.15.

要测试系统，您需要在自动打开的浏览器中导航到/orders操作并填写表单。（您只需在浏览器自动打开的 localhost URL 后面附加“orders”即可。）然后查看主机的控制台输出，您将看到它打印了收到的消息的详细信息。

To test the system, you need to navigate to the /orders action in the browser that automatically opened and fill out the form. (You just need to append “orders” to the localhost URL the browser automatically opens with.) Then look back at the console output of the host, and you will see it printing the details of the message it received.

发布事件

Publishing Events

现在，Web 应用程序正在发送销售限界上下文成功接收的命令，组件图上的第二步显示销售限界上下文需要创建订单，并在完成后发布OrderCreated事件。首先，您需要在Sales.Messages项目中定义OrderCreated事件。与创建PlaceOrder命令的方式类似，只需在项目根目录中添加一个名为Events的文件夹，然后在其中添加一个名为OrderCreated的类，如图 12.16所示。

Now that the web application is sending commands that the Sales bounded context is successfully receiving, the second step on your component diagram shows that the Sales bounded context needs to create the order and publish an OrderCreated event when it has done so. To begin, you need to define the OrderCreated event in the Sales.Messages project. Similar to the way you created the PlaceOrder command, simply add a folder called Events in the root of the project, and then add a class called OrderCreated inside it, as shown in Figure 12.16.

在OrderCreated事件中，您需要添加事件所需的必要信息。只需将它们作为属性添加到类中即可，如清单 12-6 所示。

Inside your OrderCreated event, you need to add the necessary pieces of information that are part of the event. Just add them as properties to the class, as shown in Listing 12-6.

现在您已经定义了OrderCreated事件，您可以在需要时自由发布它。要发布任何事件，请调用Bus.Publish()，并传入该事件的实例。清单 12-7 显示了更新后的PlaceOrderHandler将订单保存到数据库，然后通过发布OrderCreated事件通知相关方已完成此操作。

Now that you’ve defined the OrderCreated event, you are free to publish it when you need to. To publish any event, invokeBus.Publish(), passing in an instance of the event. Listing 12-7 shows the updated PlaceOrderHandler saving the order to the database, and then notifying interested parties it has done so by publishing an OrderCreated event.

为了使发布事件有价值，您需要能够处理它们并应用您的域策略。

For publishing events to be worthwhile, you need to be able to handle them and apply your domain policies.

使用消息网关使外部 HTTP 调用可靠

Making External HTTP Calls Reliable with Messaging Gateways

您在第 11 章中看到，响应式解决方案的主要优势之一是提高了容错能力。您看到的一个特殊场景是外部服务（例如支付提供商）的宕机。在旧的 RPC 场景中，订单会失败。但在本解决方案中，正如您将看到的，您可以使用消息网关将自身与外部服务故障隔离开来。消息网关将不可靠的通信封装在一条消息中，以便可以重试，直到受灾服务恢复可用。

You saw in Chapter 11 that one of the major benefits of a reactive solution is improved fault tolerance. One particular scenario you saw was downtime of external services, such as the payment provider. In the old RPC scenario, the order would have failed. But in this solution, as you will see, you can insulate yourself from failures that happen to external services by using a messaging gateway. Messaging gateways wrap unreliable communication with a message so that it can be retried until the stricken service is available again.

实现消息网关

Implementing a Messaging Gateway

如上所述，消息网关只是一种模式；它指的是将一个消息处理程序拆分成两个或多个，用于处理不可靠的网络通信。因此，消息框架并没有提供任何特殊功能——您只需创建并发送额外的消息即可。然而，真正的细节在于确保尽可能隔离有风险的通信。

As mentioned, messaging gateways are just a pattern; it’s a case of splitting one message handler into two or more, where there is unreliable network communication. Therefore, there is no special facility provided by messaging frameworks—you just need to create and send additional messages. The real detail, though, is ensuring that you isolate the risky communication as much as possible.

从定义消息开始

OrderCreatedHandler的首要职责是与外部供应商沟通。您可以触发一个事件来表明这种情况已经发生。但是，由于消息传递网关更多的是容错的实现细节，而不是领域事件，您不想将其暴露给其他组件。因此，使用命令来确保它只在一个地方处理是有意义的。在这个例子中，该命令被称为RecordPaymentAttempt。从组件图中您可以知道Billing.Payments.PaymentAccepted组件也需要发布一个PaymentAccepted事件。因此，您可以将这两条消息添加到一个名为Billing.Messages的新 C# 类库中。记住将命令放在Commands文件夹中，将事件放在Events文件夹中，如图12.17所示。这两条消息的格式如清单 12-10 所示。

The first responsibility of the OrderCreatedHandler is communicating with the external supplier. You could fire an event indicating this has happened. However, because the messaging gateway is more of an implementation detail for fault tolerance and not a domain event, you don’t want to expose it to other components. Therefore, it makes sense to go with a command to ensure it is only handled in a single place. In this example, the command is called RecordPaymentAttempt. You know from the component diagram that the Billing.Payments.PaymentAccepted component also needs to publish a PaymentAccepted event. So you can add both of those messages to a new C# class library called Billing.Messages. Remember to put the command in a Commands folder and the event in an Events folder, as Figure 12.17 illustrates. The format of those two messages is shown in Listing 12-10.

然后实现每个处理程序

现在，您可以添加健壮的OrderPlacedHandler了，它不会包含清单 12-9 中版本的漏洞。在此版本中，对支付提供商的调用被包装在RecordPaymentAttempt命令中。然后，在下一个处理程序中，将支付详细信息保存到数据库。不要忘记在Billing.Payments.PaymentAccepted组件中添加对Billing.Messages的引用。然后，您可以添加如清单 12-11 所示的OrderCreatedHandler。

You’re now ready to add the robust OrderPlacedHandler that doesn’t contain the vulnerabilities of the version in Listing 12-9. In this version, the call to the payment provider is wrapped with a RecordPaymentAttempt command. Saving the payment details to the database then comes in the next handler. Don’t forget to add a reference to Billing.Messages in the Billing.Payments.PaymentAccepted component. You can then add the OrderCreatedHandler shown in Listing 12-11.

需要注意的一个小细节是Bus.SendLocal()调用。希望这很有意义，因为发送组件也需要处理该命令。SendLocal ()只是将消息发送到发送该消息的同一个 NServiceBus 主机，然后它会在那里查找该消息的处理程序。

One small detail to note is the Bus.SendLocal() call. Hopefully this makes sense, because the sending component also needs to handle the command. SendLocal() just sends the message to the same NServiceBus host that sent the message, where it then looks for a handler of that message.

要完成此步骤，请为RecordPaymentAttempt命令添加一个处理程序，该命令模拟将付款记录到数据库。清单 12-12 展示了此处理程序的外观。如果这有助于您在脑海中拼凑消息流，则可以将其与OrderCreatedHandler放在同一个文件中。

To complete this step, add a handler for the RecordPaymentAttempt command that simulates recording the payment to the database. Listing 12-12 shows how this handler should look. You can put it in the same file as the OrderCreatedHandler if that helps you to mentally piece together the flow of messages.

控制消息重试

Controlling Message Retries

现在是一个真正理解使用消息传递价值的绝佳机会。您将看到消息总线在外部服务不可用时重试消息。在此过程中，本示例充分利用了您刚刚实现的消息网关。为了模拟失败，您需要修改存根支付提供程序的实现，使其在前两次调用时抛出异常，然后顺利地接受第三次请求。

Now is a great opportunity to really understand the value of using messaging. You’re going to actually see the message bus retry messages because an external service is unavailable. In the process, this example fully makes use of the messaging gateway you just implemented. What you need to do to simulate failure is change your stub payment provider implementation to throw an exception the first two times it is called and then happily accept the third request.

模拟失败

如果您更新PaymentProvider以使其类似于清单 12-13，那么您几乎就可以看到您的反应式系统的容错能力了。

If you update the PaymentProvider so that it resembles Listing 12-13, you will be almost ready to see the fault tolerance of your reactive system in action.

在本章前面测试第一个消息处理程序之前，您必须将每个 NServiceBus 组件设置为在解决方案启动时启动。现在，您还需要对Billing.Payment.PaymentAccepted组件执行此操作，以便测试消息网关。因此，请确保您的启动设置类似于图 12.18。

Before you tested your first message handler earlier in this chapter, you had to set each NServiceBus component to start up when the solution was started. You also need to do that now for the Billing.Payment.PaymentAccepted component so that you can test your messaging gateway. So ensure you’re start-up settings resemble Figure 12.18.

现在您可以按 F5 运行应用程序。完成后，在浏览器中导航到/orders页面并下订单。请特别注意Billing.Payments.PaymentAccepted组件的控制台窗口。首先，您会看到OrderCreatedHandler收到了OrderCreated事件。在其下方，您会看到PaymentAccepted事件已发布，如图12.19所示。但是，如果您在控制台中向上滚动窗口，你实际上看到这是第三次尝试。图 12.20展示了 NServiceBus 在处理第一条消息失败时打印到控制台的消息。看看它甚至显示了你在存根支付提供商中抛出的异常类型和消息：System.Exception: Service unavailable. Down for maintenance（系统异常：服务不可用，停机维护）。

Now you can press F5 to run the application. After you’ve done that, navigate to the /orders page in your browser and place an order. Pay special attention to the console window for the Billing.Payments.PaymentAccepted component. At first you will just see that OrderCreatedHandler received the OrderCreated event. Below that you’ll see that the PaymentAccepted event was published, as shown in Figure 12.19. But if you scroll up in the console window, you actually see that was the third attempt. Figure 12.20 shows you the messages NServiceBus printed to the console when it failed to process the first message. Look how it even shows the exception type and message you threw in your stub payment provider: System.Exception: Service unavailable. Down for maintenance.

二级重试

如果支付提供商长时间处于宕机状态，比如十分钟，NServiceBus 可能已经达到了重试消息的次数限制。幸运的是，NServiceBus 有一个称为2 级重试 的功能，允许您指定覆盖更长持续时间的自定义重试周期。在此示例中，每十分钟重试一次消息，持续一小时会很有用。清单 12-14 中的配置展示了如何执行此操作。

If the payment provider is down for a long time, say ten minutes, NServiceBus may have reached the limit for the number of times it retries the message. Fortunately, NServiceBus has a feature called 2nd level retries, allowing you to specify custom retry periods that cover longer durations. In this example, it would be useful to retry the message every ten minutes for an hour. The configuration in Listing 12-14 shows how to do that.

有时，消息永远不会成功，因为系统无法处理它们。可能是消息未得到正确验证，或者处理该消息所需的数据被从数据库中删除。这些被称为毒害消息，最终必然会被放入错误队列。您将在本章后面了解更多关于错误队列的信息，包括如何监控它以及如何处理最终进入错误队列的消息。

Sometimes messages will never succeed because the system cannot handle them. Perhaps a message wasn’t validated properly, or data got wiped from the database that needed to be looked up to process the message. These are known as poison messages and inevitably end up in the error queue. You’ll learn more about the error queue later in this chapter, including how to monitor it and handle messages that end up in it.

实践中的最终一致性

Eventual Consistency in Practice

在下单流程的这个阶段，系统可以被认为处于不一致状态。尽管订单是由销售限界上下文创建的，并且付款已由结算限界上下文处理，但发货限界上下文并不知道这一点，因此尚未安排​​发货。在某些系统中，这种情况永远不会发生，因为整个流程是一个原子事务，要么完全成功，要么完全失败。因此，这可以被视为最终一致性的一个例子。当您使用消息传递集成限界上下文时，这是一个学习如何处理最终一致性的好时机。

At this point in the place order process, the system could be considered to be in an inconsistent state. Although the order was created by the Sales bounded context and payment has been processed by the Billing bounded context, the Shipping bounded context does not know this and hasn’t arranged shipping yet. This would never happen in some systems, where the whole series is a single atomic transaction that succeeds or fails completely. So this can be considered an example of eventual consistency. It’s an opportune moment for you to learn how to deal with eventual consistency when you are integrating bounded contexts using messaging.

向新州迈进

Rolling Forward into New States

为了处理订单失败的最终一致性问题，您可以与业务部门合作，创建一个新的支付失败用例的组件图，并用它来查看需要进入的状态。假设您与业务部门沟通后，被告知当付款被拒绝时，销售团队有责任通知客户订单已被取消。图 12.21展示了此用例的部分组件图。

To deal with the eventual consistency of a failed order, you can work with the business to create a new component diagram of the payment failed use case and use it to see what state you need to move into. Imagine that you did speak to the business and were told that when a payment is rejected, it is the Sales team’s responsibility to inform the customer the order was cancelled. Figure 12.21 shows a partial component diagram for this use case.

如图 12.21所示，要处理这种最终一致的场景，您只需在账单限界上下文中发布一个PaymentRejected事件，并在销售限界上下文中通过向客户发送电子邮件来处理该事件。要实现此用例，您只需发送和处理几条消息。为了避免此处未展示的重复，您可以参考前面的示例自行实现。

As you can see in Figure 12.21, all you need to do to deal with this eventually consistent scenario is publish a PaymentRejected event in the Billing bounded context and handle it in the Sales bounded context by sending an e-mail to the customer. To implement this use-case you just need to send and handle a few messages. To avoid repetition that is not shown here, you can implement it yourself if you want to using previous examples as a guide.

有界上下文在本地存储所需的所有数据

Bounded Contexts Store All the Data They Need Locally

组件图上的下一步（步骤 4 的剩余部分，然后是步骤 5 和步骤 6）涉及安排发货的 Shipping 限界上下文。但有一个问题。再次查看PaymentAccepted事件：

The next steps on your component diagram (remainder of 4, then 5, and 6) involve the Shipping bounded context arranging shipping. But there’s a problem. Look at the PaymentAccepted event again:

public class PaymentAccepted
        {
        public string OrderId { get; set; }
        }

public class PaymentAccepted
        {
        public string OrderId { get; set; }
        }

如果您只有订单 ID，该如何安排发货？很遗憾，您无法做到，因此您需要仔细考虑各种选择。为了简单起见，假设每个用户只有一个地址，并且该地址位于Sales.Customers业务组件的数据库中。一种选择是使用 HTTP 通过 RPC 连接到Sales.Customers业务组件以获取所需数据。但这样一来，您就引入了时间耦合。如果Sales.Customers数据库或 RPC 端点发生故障，发货限界上下文将无法正常工作。如果其他限界上下文直接连接到Sales.Customers数据库，销售开发团队将无法根据自身的最佳需求重构或更改数据库，而又担心会破坏其他限界上下文。

How can you arrange shipping when all you have is the ID of an order? Unfortunately, you can’t, so you need to carefully consider your options. To keep things simple, imagine that each user has just one address and it lives inside the database belonging to the Sales.Customers business component. One option is to RPC across to the Sales.Customers business component using HTTP to get the data you need. But then you’ve introduced a temporal coupling. If the Sales.Customers database or RPC endpoint goes down, the Shipping bounded context cannot function. If other bounded contexts went straight to the Sales.Customers database, the Sales development team would not be able to refactor or change the database according to their own best needs without worry of breaking other bounded contexts.

另一种选择是在PaymentAccepted事件中发布客户的地址。这种方法也很危险，因为本质上，您是在通过将第一条消息的属性添加到第二条消息来聚合两条消息。在发送四条消息的用例中，第四条消息需要包含前三条消息的所有属性。这可能会导致高耦合度，并且难以调试数据来源。出于务实的考虑，您可以尝试在某些地方使用这种方法，但除非您有令人信服的业务案例，否则强烈建议不要这样做。

Another option is to publish the customer’s address on the PaymentAccepted event. This approach is also dangerous because, essentially, you are aggregating two messages by adding the properties from the first message to the second. In a use case in which four messages are sent, the fourth message needs to contain all the properties of the first three. This could cause high coupling and hard-to-debug issues trying to work out where data came from. Being pragmatic, you could try to get away with it in a few places, but it’s highly unrecommended unless you have a compelling business case.

存储成本低廉——保留本地副本

Storage Is Cheap—Keep a Local Copy

在这种情况下，许多团队为了减少不必要的耦合，会选择将每个有界上下文所需的所有数据存储在本地。这通常是一个不错的选择，因为如今存储成本低廉。例如，在撰写本文时，您可以花大约 50 美元购买 1TB 的硬盘。这意味着销售有界上下文和发货有界上下文都应该存储客户的地址。很快您就会看到人们对此的一些担忧，但现在只需尝试使用这种方法实现发货有界上下文即可。这些问题稍后会得到解决。

An option that many teams take in this situation to reduce unwanted coupling is to store all the data each bounded context needs locally. This is often a good trade-off because storage is cheap these days. As an example, you can buy a 1TB hard drive for around $50 at the time of writing. What this means to you is that both the Sales bounded context and the Shipping bounded context should store the customer’s address. Shortly you’ll see some of the concerns people have with this, but for now just try to focus on implementing the Shipping bounded context using this approach. Those concerns will be addressed afterward.

图 12.22展示了用户注册流程。请注意，事件NewBusinessUserRegistered是如何发布的，以及两个有界上下文如何订阅此事件。“运输”有界上下文的“常客”业务组件接收客户的 ID 和地址。“营销”有界上下文的“在线营销”业务组件接收客户的 ID 地址以及业务所在的市场。这两个有界上下文都将数据存储在本地，即使相同的初始数据被存储在多个位置。

Figure 12.22 illustrates the user registration process. Notice how an event is published—NewBusinessUserRegistered—and two bounded contexts subscribe to this event. The Shipping bounded context’s Regular Customers business component takes the customer’s ID and address. The Marketing bounded context’s Online Marketing business component takes the customer’s ID address, and the market the business operates in. Both bounded contexts store the data locally, even though it’s the same initial data being stored in multiple places.

要实现本章构建的电子商务系统的剩余部分，您将使用本地存储。在此之前，您需要创建Shipping.BusinessCustomers.ArrangeShipping组件，该组件订阅销售边界上下文的OrderCreated事件和计费边界上下文的PaymentAccepted事件。您可以通过执行以下步骤进入该阶段：

To implement the remaining part of the e-commerce system you’ve been building in this chapter, you’ll use local storage. Before that, you need to create the Shipping.BusinessCustomers.ArrangeShipping component that subscribes to the Sales bounded context’s OrderCreated event and the Billing bounded context’s PaymentAccepted event. You can get to that stage by carrying out the following steps:

1. 创建一个名为Shipping.BusinessCustomers.ShippingArranged的​​新 C# 类库。
2. Create a new C# class library called Shipping.BusinessCustomers.ShippingArranged.
3. 添加对Sales.Messages和Billing.Messages项目的引用。
4. Add a reference to the Sales.Messages and Billing.Messages projects.
5. 使用 NuGet 包管理器添加 NServiceBus 依赖项。
6. Add the NServiceBus dependencies using the NuGet Package Manager.
7. 将用于定位命令和事件的约定复制到EndpointConfig中。同时使EndpointConfig继承AsA_Publisher和IWantCustomInitialization，如清单 12-15 所示。
8. Copy across the conventions for locating commands and events into EndpointConfig. Also make EndpointConfig inherit AsA_Publisher and IWantCustomInitialization, as Listing 12-15 illustrates.
9. 向项目中添加OrderCreatedHandler和PaymentAcceptedHandler ，如清单 12-16 所示。
10. Add an OrderCreatedHandler and PaymentAcceptedHandler to the project, as shown in Listing 12-16.
11. 将OrderCreated和PaymentAccepted事件的订阅配置添加到项目的App.config中。您的App.config应类似于清单 12-17。
12. Add subscription configuration for the OrderCreated and PaymentAccepted events to the project’s App.config. Your App.config should then resemble Listing 12-17.
13. 配置项目启动。
14. Configure the project to start up.
15. 添加一个名为Shipping.Messages的 C# 类库，其中包含一个Events文件夹，其中包含清单 12-18 所示的ShippingArranged事件。
16. Add a C# class library called Shipping.Messages with an Events folder containing the ShippingArranged event shown in Listing 12-18.
17. 在Shipping.BusinesCustomers.ArrangeShipping组件中添加对Shipping.Messages项目的引用。
18. Add a reference to the Shipping.Messages project in the Shipping.BusinesCustomers.ArrangeShipping component.
19. 配置Shipping.BusinessCustomers.ArrangeShipping项目以在 Visual Studio 中启动。
20. Configure the Shipping.BusinessCustomers.ArrangeShipping project to start up in Visual Studio.

如果您已正确完成所有操作，您的系统现在应该可以正常工作，直到安排发货为止。请尝试按 F5 运行应用程序，导航到/orders页面并填写表单。然后，您会看到三个控制台窗口出现，每个组件一个。在Shipping.BusinessCustomer.ArrangeShipping控制台中，您应该看到ArrangeShipping 组件存储了来自 Sales 边界上下文的OrderCreated事件的UserId和OrderId，然后在处理PaymentAccepted事件时使用UserId查找地址。您应该看到如图 12.23所示的控制台输出（其中包含您在表单中输入的值）。

If you’ve done everything correctly, your system should now be working up to the point of arranging shipping. Try running the application by pressing F5, navigating to the /orders page, and filling out the form. You then see three console windows appear—one for each component. Inside the Shipping.BusinessCustomer.ArrangeShipping console you should see that the ArrangeShipping component stored the UserId and OrderId from the Sales bounded context’s OrderCreated event, and it then used the UserId to look up the address when it handled the PaymentAccepted event. You should see console output that looks like Figure 12.23 (with the values you entered into the form).

   public class PriceUpdated
   {
       public string ProductId { get; set; }

       public double Price { get; set; }

       public DateTime AvailableFrom { get; set; }

       public DateTime AvailableTo { get; set; }
    }

   public class PriceUpdated
   {
       public string ProductId { get; set; }

       public double Price { get; set; }

       public DateTime AvailableFrom { get; set; }

       public DateTime AvailableTo { get; set; }
    }

在 UI 中整合所有内容

Pulling It All Together in the UI

正如您在本章中到目前为止所见，将数据推送到消息系统只是故事的一部分。您还需要能够从消息系统中获取数据。同样，与某些传统做法相比，这可能需要不同的思维方式，尤其是在您将数据存储在每个业务组件本地时。您在图 12.4所示的容器图中看到了如何实现这一点的线索。答案是，有界上下文通常需要通过 HTTP 暴露其数据以供 Web 应用程序获取。

Pushing data into a messaging system, as you’ve seen so far in this chapter, is only part of the story. You also need to be able to get data out of the messaging system. Again, this can require a different mind-set compared to some traditional practices, especially when you are storing data locally in each business component. You saw a clue about how to achieve this in the containers diagram illustrated in Figure 12.4. The answer is that bounded contexts often need to expose their data over HTTP for web applications to fetch.

在下一章中，您将看到许多构建 HTTP API 以公开域功能和数据的良好实践和具体示例。在本节中，您将了解一些在消息传递系统中尤为重要的概念和权衡取舍。不过，下一章中的许多其他概念在某种程度上仍然适用。

In the next chapter, you will see lots of good practices for, and concrete examples of, building HTTP APIs to expose your domain functionality and data. In this section, you’ll learn about a few of the concepts and trade-offs that are especially important in messaging systems. Many of the other concepts from the next chapter will still be relevant to some extent, though.

业务组件需要自己的 API

Business Components Need Their Own APIs

如果遵循每个业务组件都有自己的私有数据库的原则，那么与 Web 应用程序共享数据的唯一合理方法是每个业务组件都有自己的一组 API 来公开这些数据。图 12.24可视化了这种建议的布局。

If you work to the principle that each business component has its own private database, the only sensible way to share data with a web application is for each business component to have its own set of APIs exposing that data. Figure 12.24 visualizes this suggested layout.

如图 12.24所示，一些业务组件选择使用两个 Web 应用程序来公开其数据。相比之下，其他业务组件不提供 API，因为它们不公开数据；它们只是使用数据并执行其他任务。在业务组件内部，您可以自由地进行操作。项目数量、API 数量，甚至所使用的技术都取决于您的最佳判断和项目需求。

As you can see in Figure 12.24, some business components have chosen to have two web applications exposing their data. In contrast, other business components do not provide APIs because they do not expose data; they simply consume it and carry out other tasks. Inside your business components, you are free to do as you please. The number of projects, the number of APIs, and even the technologies used are down to your best judgment and the needs of the project.

警惕服务器端编排

Be Wary of Server-Side Orchestration

在服务器端（控制器内部）查询所有 API，然后将组合模型发送到网页，这种做法可能很诱人。然而，这却会抵消构建松耦合、容错系统所付出的大量努力，因为你又引入了一个耦合点。首先，如果其中一个 API 发生故障，可能会出现错误，导致页面无法渲染。不过，仔细想想，这真的有必要吗？想象一下，你构建了一个显示产品目录的页面，并在页面底部展示了特价商品。图 12.25通过展示页面的不同部分如何从不同的 API 获取数据，对此进行了示例说明。

It can be tempting to query all your APIs on the server (inside a controller) and send a combined model to the web page. Unfortunately, this can undo a lot of the hard work of building a loosely coupled, fault-tolerant system, because you have introduced another coupling point. First, if one of the APIs is down, there may be an error and the page may not render. Think carefully, though. Is that really necessary? Imagine that you built a page showing a catalogue of products, at the bottom of which page you showed special offers. Figure 12.25 exemplifies this by indicating how different parts of the page get their data from different APIs.

如果“营销”限界上下文出现问题，无法提供特价优惠，您认为企业会希望客户看到一个错误屏幕，阻止他们消费吗？有些企业肯定希望即使无法显示特价优惠，也能继续显示主产品列表。您可以通过服务器端编排来实现这一点，但这需要更多精力，而且很容易被遗忘。此外，Web 应用程序中执行编排的控制器是一个额外的组件，可能会失败。出于这些原因，有些团队更喜欢使用 AJAX 直接从页面内部加载数据。

Do you think the business would want customers to see an error screen preventing them from spending money if the Marketing bounded context was experiencing issues and could not provide the special offers? Some businesses would definitely prefer you to still show the main list of products, even if you couldn’t show the special offers. You could do this with server-side orchestration, but it requires more effort and can easily be forgotten. Also, the controller in your web application that performs the orchestration is an extra component that could fail. Some teams prefer to load the data directly from within the page using AJAX for these reasons.

消息版本控制

Message Versioning

在某些时候，您几乎肯定会需要更改消息的格式。但消息格式是两个团队之间的契约。任何格式的更改都可能需要两个团队的输入和协作。虽然这些情况不可避免，但松耦合的面向服务架构 (SOA) 系统的目标之一是避免团队之间互相拖累。更改多个有界上下文之间的契约就可能发生这种情况。

At some point, you will almost certainly be required to change the format of a message. But the message format is the contract between two teams. Any changes to the format may require input and collaboration from both teams. Although these scenarios are inevitable, one of the goals of loosely coupled Service Oriented Architecture (SOA) systems is that teams don’t slow each other down. Changing the contract between multiple bounded contexts is a situation in which this could happen.

如果您只是更改消息格式并进行部署，那么尚未升级到新格式的系统将无法正常工作。您需要一种策略，让您能够以不影响现有消费者的方式更新消息格式。这样，所有相关团队都可以在需要时更新到新格式。在此之前，他们只能使用旧格式。这就是为什么在更改消息格式时需要追求向后兼容性。

If you were to just change the format of a message and deploy it, the systems that had not upgraded to the new format wouldn’t work anymore. What you need is a strategy that allows you to update message formats in a way that doesn’t break existing consumers. This would then allow all the teams involved to update to the new format when it was important for them to do so. Until then, they could use the old format. This is why you need to aim for backward compatibility when you change message formats.

  public class OrderCreated
  {
      public string OrderId { get; set; }

      public string UserId { get; set; }

      public string[] ProductIds { get; set; }

      public string ShippingTypeId { get; set; }

      public DateTime TimeStamp { get; set; }

      public double Amount { get; set; }
  }

  public class OrderCreated
  {
      public string OrderId { get; set; }

      public string UserId { get; set; }

      public string[] ProductIds { get; set; }

      public string ShippingTypeId { get; set; }

      public DateTime TimeStamp { get; set; }

      public double Amount { get; set; }
  }

监控和扩展

Monitoring and Scaling

当系统启动并运行时，密切关注任何错误非常重要，以确保用户获得可接受的服务水平。衡量 SLA 和业务指标也很重要，这样企业就可以将其作为制定关键决策的依据，例如如何改进产品或业务模式。衡量 SLA 还可以告知开发团队系统何时运行缓慢，何时需要考虑扩展。现在您将了解如何使用 NServiceBus 处理错误、衡量技术和业务指标以及扩展有界上下文。这些概念也适用于其他消息传递框架，尽管它们的实现方式可能有所不同。

When a system is up and running, it’s important to keep any eye on errors to ensure that users are getting an acceptable level of service. It’s also important to measure SLAs and business metrics so that the business can use them as the basis for making key decisions, such as how to evolve the product or the business model. Measuring SLAs also informs the development team when the system is too slow and it’s time to consider scaling. You’ll now see how to handle errors, measure technical and business metrics, and scale bounded contexts using NServiceBus. These concepts should apply to other messaging frameworks, too, although they will be implemented differently, of course.

监控错误

Monitoring Errors

您在本章前面看到，未成功传递或处理的消息会被重试。但在该示例中，您只是添加了一些逻辑来确保支付提供商仅失败两次。这被称为暂时性错误，因为这种情况会在一段时间后自行解决。然而，有时错误并非暂时性的，无论消息重试多少次，它总是会失败。这些是有害消息（http://msdn.microsoft.com/en-us/library/ms166137.aspx 上有更详细的讨论）。在某个时候，您的消息传递框架将停止重试有害消息。然后，大多数消息传递框架会将它们放入一个名为错误队列的特殊队列中，需要手动干预才能删除这些消息。

You saw earlier in this chapter that messages that are not successfully delivered or processed are retried. In that example, though, you just added some logic to ensure the payment provider only failed twice. This is known as a transient error, because the situation resolves itself after some time. However, sometimes errors are not transient, and no matter how many times a message is retried, it always fails. These are poison messages (discussed in more detail at http://msdn.microsoft.com/en-us/library/ms166137.aspx). At some point, your messaging framework will stop retrying poison messages. Most messaging frameworks then put them in a special queue called the error queue, where manual intervention is required to remove the messages.

您可以通过更新某个消息处理程序使其始终抛出异常来查看错误队列的实际运行情况。尝试替换Sales.Orders.OrderCreated.PlaceOrderHandler的Handle()方法中的逻辑，使其模拟永久错误情况，如下所示：

You can see the error queue in action by updating one of your message handlers to always throw an exception. Try replacing the logic in your Sales.Orders.OrderCreated.PlaceOrderHandler’s Handle() method so that it simulates a permanent error condition as follows:

public void Handle(PlaceOrder message)
{
    throw new Exception("I have received a poison message");
}

public void Handle(PlaceOrder message)
{
    throw new Exception("I have received a poison message");
}

现在运行应用程序并下订单会导致消息反复失败，并最终进入发送有害消息的组件的错误队列。（您需要等待控制台中出现红色错误消息。）为了确认这一点，您需要在 Visual Studio 中激活服务器资源管理器，展开“服务器”，展开您的计算机名称，然后展开“消息队列”。最后，您可以展开“私有队列”节点并检查错误队列的内容，如图12.26所示。

Running your application and placing orders now causes the message to repeatedly fail and ultimately end up in the error queue of the component that sends the poison message. (You need to wait for a red error message to appear in the console.) To confirm this, you need to activate the Server Explorer in Visual Studio, expand Servers, expand the name of your machine, and then expand Message Queues. Finally, you can expand the Private Queues node and examine the contents of the error queue, as shown in Figure 12.26.

要检查错误队列中的所有消息，请展开“队列消息”节点。如果要检查单条消息的内容，请右键单击该消息，然后选择“属性”。突出显示BodyStream行，然后点击右侧列中出现的三个点的按钮。图 12.27展示了查看错误队列中消息的BodyStream值的示例。

To inspect all the messages in the error queue, expand the Queue messages node. If you want to inspect the contents of a single message, right-click on it and choose Properties, highlight the BodyStream row, and click the button with three dots that appears in the right column. Figure 12.27 shows an example of viewing the BodyStream value of a message in the error queue.

监控错误队列是一项重要的活动，可以帮助您快速发现生产环境中的错误。但如何实际监控队列则取决于您自己。幸运的是，您有很多选择。例如，您可以使用开源 Wolfpack 监控工具 ( http://wolfpack.codeplex.com/ )，甚至可以创建自己的监控系统。

Monitoring the error queue is an important activity that lets you spot production bugs quickly. But how you actually monitor the queue is up to you. Fortunately, you have a number of choices. For example, you can use the Open Source Wolfpack monitoring tool (http://wolfpack.codeplex.com/) or even create your own monitoring system.

一旦消息被放入错误队列，就需要人工干预来确定接下来的处理方式。检查消息后，您可能会发现问题已经解决，消息应该没有问题（这实际上是一个瞬时错误），或者代码中存在错误，这意味着该消息永远无法成功处理。无论哪种情况，当问题解决后，NServiceBus 都会附带一个工具，将所有消息发送回其队列，以便再次尝试处理（ReturnToSourceQueue.exe）。

Once a message is put in an error queue, manual intervention is required to determine what happens to it next. After inspecting the message, you might realize that the problem has gone away and the message should be fine (it was really a transient error), or there is an error in the code, meaning the message will never successfully be handled. Either way, when the problem has been fixed, NServiceBus ships with a tool that sends all messages back to their queue so they can be attempted again (ReturnToSourceQueue.exe).

您可以从 NServiceBus 文档（http://support.nservicebus.com/customer/portal/articles/860511-getting-started—fault-tolerance）了解有关监控和处理错误的更多信息。

You can learn more about monitoring and dealing with errors from the NServiceBus documentation (http://support.nservicebus.com/customer/portal/articles/860511-getting-started—fault-tolerance).

<TransportConfig MaxRetries="5" MaximumConcurrencyLevel="4" />

<TransportConfig MaxRetries="5" MaximumConcurrencyLevel="4" />

消息传递桥

Messaging Bridge

当两个独立的消息系统需要共享消息时，消息桥（http://www.eaipatterns.com/MessagingBridge.html）是解决这个问题的一种方法。通常，使用两个独立的框架无法形成单一、完全连接的消息总线，但通过使用消息桥，您可以连接每个消息系统的端点，从而有效地创建链路，如图12.29所示。

When you have two separate messaging systems that need to share messages, a messaging bridge (http://www.eaipatterns.com/MessagingBridge.html) is one way of addressing the issue. It’s usually not possible to form a single, fully connected message bus using two independent frameworks, but by using a messaging bridge, you can connect individual endpoints from each messaging system to effectively create a link, as illustrated in Figure 12.29.

实现消息桥通常只需创建一个应用程序，该应用程序可以从一个消息系统接收消息，并将其传递给另一个消息系统。在您的电子商务系统中，这需要为 OrderCreated_V2 事件创建一个新的订阅者，该订阅者会转换该事件，然后将其推送到使用 Mass Transit 的新限界上下文中。

Implementing a messaging bridge usually just involves creating an application that can receive messages from one messaging system and hand them over to the other. In your e-commerce system, it’s a case of creating a new subscriber to the OrderCreated_V2 event that converts the event and then pushes it into the new bounded context that uses Mass Transit.

在构建它之前，你需要先构建一个使用公共交通的促销有界上下文。在此之前，你需要先简单介绍一下公共交通。

Before you can build that, you need to build the Promotions bounded context that uses Mass Transit. And before that, you need a brief introduction to Mass Transit.

公共交通

Mass Transit

多样性通常是一件好事，这就是为什么 .NET 开发者很幸运能够拥有 Mass Transit ( http://masstransit-project.com/ )——一个可以替代 NServiceBus 的消息传递框架，可以独立使用，也可以与其他消息传递框架配合使用。本例演示了后者。尽管 Mass Transit 的实现方式不同，并且有自己的 API，但它仍然与 NServiceBus 有很多共同之处。

Variety is often a good thing, which is why .NET developers are lucky to have Mass Transit (http://masstransit-project.com/)—an alternative messaging framework to NServiceBus that can be used stand-alone or alongside other messaging frameworks. The latter case is demonstrated in this example. Although it is implemented differently and has its own API, Mass Transit still shares many commonalities with NServiceBus.

Install-Package MassTransit
–ProjectName Promotions.LuckyWinner.LuckyWinnerSelected
- Version 2.9.5

Install-Package MassTransit
–ProjectName Promotions.LuckyWinner.LuckyWinnerSelected
- Version 2.9.5

Install-Package MassTransit.msmq
–ProjectName Promotions.LuckyWinner.LuckyWinnerSelected
- Version 2.9.5

Install-Package MassTransit.msmq
–ProjectName Promotions.LuckyWinner.LuckyWinnerSelected
- Version 2.9.5

Bus.Instance.Publish(new LuckyWinnerSelected(UserId ="user123"));

Bus.Instance.Publish(new LuckyWinnerSelected(UserId ="user123"));

测试一下

Testing It Out

您的消息桥现在应该可以正常工作了，因此新的 Promotions 限界上下文应该能够处理OrderCreated事件。您只需要提供相关证明。要测试应用程序，请执行以下步骤：

Your messaging bridge should now be working, so your new Promotions bounded context should be able to handle OrderCreated events. All you need is proof of this. To test the application, carry out the following few steps:

1. 按照此博客文章中的建议将应用程序设置为启动项目和控制台应用程序：http://possiblythemostboringblogever.blogspot.co.uk/2012/08/creating-console-app-in-visual-studio.html。
2. Set the application as a start-up project and a console application following the advice in this blog post: http://possiblythemostboringblogever.blogspot.co.uk/2012/08/creating-console-app-in-visual-studio.html.
3. 运行系统（按F5）。
4. Run the system (press F5).
5. 像以前一样下订单（浏览至/orders）。
6. Place an order as before (browse to /orders).
7. 检查 NServiceBus 控制台是否像以前一样打印消息。
8. Check that the NServiceBus consoles are printing the messages as they previously did.
9. 检查公共交通组件的控制台是否收到了OrderCreated事件。如果一切正常，控制台应该类似于图 12.30。（根据您在表单中输入的用户 ID，您的控制台可能有所不同。）
10. Check that the console for the Mass Transit component received the OrderCreated event. If it all works, the console should resemble Figure 12.30. (Yours will be different based on the user ID you entered into the form.)

无平台耦合

No Platform Coupling

由于 HTTP 是一种平台无关的协议，因此每个与 HTTP 集成的应用程序或组件都可以使用任何技术构建。这不仅有利于创建松耦合的应用程序，而且还有助于创建彼此之间依赖关系较少的松耦合团队。

Each application or component that integrates with HTTP may be built using any technology thanks to HTTP being a platform-agnostic protocol. Not only is this beneficial for creating loosely coupled applications, but it can help to create loosely coupled teams that have few dependencies on each other.

使用 HTTP 时，每个有界上下文都必须遵守其公共契约，即 HTTP 请求和响应格式。只要遵守这些契约，团队就可以自由地进行重构，使用新技术重写应用程序，或按照自己的节奏继续增加业务价值。重要的是，他们必须遵守公共契约，以确保与其他有界上下文的集成保持完整。

Using HTTP, each bounded context must honor its public contracts, which are the HTTP request and response formats. Providing the contracts are adhered to, teams are then free to mercilessly refactor, rewrite their applications in new technologies, or continue to add business value at their own pace. All that matters is that they honor their public contract so that integration with other bounded contexts remains intact.

每个人都理解 HTTP

Everyone Understands HTTP

HTTP 无处不在。几乎所有编程语言和运行时都拥有丰富的库和对 HTTP 的支持。因此，在集成 HTTP 时，您可以获得大量的支持。在本章中，您将了解到 .NET 拥有许多用于构建基于 HTTP 的集成的框架，包括 Windows Communication Foundation (WCF) 和 ASP.NET Web API。

HTTP is everywhere. Almost all programming languages and run times have a wealth of libraries and support for using HTTP. So when integrating with HTTP, there is a massive amount of support available to you. In this chapter, you learn that .NET has a number of frameworks, including Windows Communication Foundation (WCF) and ASP.NET Web API, for building HTTP-based integrations.

当你需要扩充团队时，每个人都了解 HTTP 的另一个好处是。找到一位了解 HTTP 的开发人员很容易，但找到一位了解消息传递系统或特定消息传递框架的开发人员通常更具挑战性。

Another advantage to everyone understanding HTTP comes when you need to expand your team. It’s easy to find a developer who understands HTTP, but it can often be more challenging to find a developer who understands messaging systems or particular messaging frameworks.

大量成熟的工具和库

Lots of Mature Tooling and Libraries

除了用于构建基于 HTTP 的集成的现代框架和库之外，还有一些先进的工具。例如，当您将 Visual Studio 指向特定类型的 Web 服务时，它会为您生成类。这些类提供模拟 HTTP Web 服务 API 的方法，因此您可以编写看似标准的面向对象代码，但实际上却是通过网络进行通信的。稍后的 WCF 示例将演示这一点。

On top of the modern frameworks and libraries for building HTTP-based integrations, some tooling is advanced. One example of this is the way Visual Studio generates classes for you when you point it to a particular type of web service. The classes provide methods that mimic the API of the HTTP web services, so you can write what appears to be standard object-oriented code yet is actually communicating across the network. This is demonstrated later in the WCF examples.

测试你的 API

Dogfooding Your APIs

当所有通信都通过 HTTP 进行时，可能不需要专门的通道来进行内部和外部通信。简而言之，这意味着您可以构建 API，有界上下文用于通信，第三方可以使用相同的 API。相比之下，消息传递系统几乎总是仅供内部使用，因此也必须生成 API。

When all your communication is over HTTP, there may be no need to have dedicated channels for internal and external communication. In plain English, this means that you can build APIs that bounded contexts use to communicate, and third parties can use those same APIs. In contrast, messaging systems are almost always for internal use only, so APIs have to be produced as well.

在内部使用与客户和合作伙伴共享的 API 的做法称为内部测试 (dogfooding)。内部测试非常可取，因为它可以帮助您获得与客户相同的体验。如果您的 API 包含一些让客户感到厌烦的痛点，内部测试或许能帮助您找到并消除这些痛点。当然，在某些情况下，内部测试也有缺点，可能并非最佳方法。例如，当您需要在内部而非外部提供更强大的性能保证时。

The practice of using the APIs internally that you share with clients and partners is known as dogfooding. Dogfooding is desirable because it helps you get the same experience as your customers. If your API contains pain points that are putting customers off, dogfooding might help you find and remove them. Of course, in some situations, dogfooding has drawbacks and might not be the best approach. One example might be when you need to have stronger performance guarantees internally than externally.

通过 HTTP 实现 RPC

Implementing RPC over HTTP

在实现基于 HTTP 的 RPC 时，您有几种选择。传统的选择是使用一种名为 SOAP（简单对象访问协议）的协议，它在 HTTP 之上添加了另一层。然而，近年来，SOAP 的流行度大幅下降。如今，更现代的方法是简单地使用简单的可扩展标记语言 (XML) 或 JavaScript 对象表示法 (JSON) 作为 RPC 调用中的有效负载。为了帮助您做出明智的决定，本节将介绍这两种选择，首先介绍 SOAP。

You have a few choices when it comes to implementing RPC over HTTP. The traditional choice has been to use a protocol called SOAP (Simple Object Access Protocol), which adds another layer on top of HTTP. In recent years, however, SOAP has seen a massive decline in popularity. Nowadays, the more modern approach is to simply use plain eXtensible Markup Language (XML) or JavaScript Object Notation (JSON) as the payload in an RPC call. So that you can make informed decisions, you’ll see both options in this section, starting with SOAP.

肥皂

SOAP

SOAP 通过在有效负载中包含丰富的信息（例如类型和函数元数据）来完全拥抱 RPC 的概念。这使得将 SOAP 消息的内容转换为远程接收方的方法调用变得轻而易举。由于 SOAP 消息的丰富性以及在上一代开发者中的广泛应用，SOAP 的工具支持也得到了进一步的提升，您稍后会看到这一点。

SOAP fully embraces the concept of RPC by including rich information in the payload, such as type and function meta data. This makes it easy to convert the contents of a SOAP message into a method call on the remote receiver. Due to this richness and being massively popular with the previous generation of developers, the tooling support for SOAP is advanced, as you’ll see shortly.

为了了解 SOAP 并体验围绕它构建的高级工具，本节将集成两个构成社交媒体应用程序的有界上下文。在本场景中，假设您是一家初创公司的成员，正在构建一款类似 Twitter 的产品，该产品在市场上越来越受欢迎，用户群也在迅速增长。

To learn about SOAP and play with the advanced tooling that has been built around it, in this section you integrate two bounded contexts that form part of a social media application. For this scenario, envision that you are part of a start-up building a Twitter-like product that’s gaining traction in the market and a rapidly increasing user base.

在本例中，您将使用 RPC 来帮助开发团队加快开发速度。目前，他们有一个单体式的“大泥球”（BBoM）应用程序，其中的有界上下文仅仅是相互之间存在二进制依赖关系的库。当一个有界上下文的更改影响到其他有界上下文时，问题会波及整个业务。您将通过将每个有界上下文隔离为独立的应用程序来解决这个问题，这些应用程序只能通过 HTTP 进行通信。为了使这种转换尽可能无缝且快速，您将使用 RPC 将从一个有界上下文到另一个有界上下文的进程内方法调用替换为通过网络进行的 RPC（完全消除二进制依赖）。这将演示 RPC 如何几乎无需修改代码，并且几乎不影响网络。

For this example, you are going to use RPC to help the development teams move faster. Currently they have a single, monolithic, Big Ball of Mud (BBoM) application where bounded contexts are merely libraries that have a binary dependency on each other. This is causing problems to ripple across the entire business when changes to one bounded context are breaking others. You’re going to remove this problem by isolating each bounded context as a standalone application that can only be communicated with over HTTP. To make this transition as seamless and rapid as possible, you’ll use RPC to replace in-process method calls from one bounded context to another with RPCs over the network (completely removing the binary dependency). This will demonstrate how RPC requires few changes to your code and makes the network almost invisible.

针对 RPC 进行设计

RPC 的设计涉及确定哪些方法调用将通过网络进行 RPC。除此之外，您的代码看起来与在单机上运行基本相同。图 13.1展示了当前场景的新设计。请注意，它如何将两个有界上下文之间的方法替换为通过网络的 RPC。

Designing for RPC involves deciding which method calls will be RPCs across the network. Apart from that, your code will mostly look the same as it did running on a single machine. Figure 13.1 shows the new design for the current scenario. Note how it replaces methods between two bounded contexts with RPCs across the network.

在（虚构的）当前系统中，Discovery 限界上下文正在调用FollowerDirectory类的FindUsersFollowers()方法，而该类属于 Account Management 限界上下文。这是一个需要进程内通信的二进制依赖关系。代码示例 13-1 演示了这一点。

In the (fictitious) current system, the Discovery bounded context is calling FindUsersFollowers() on the FollowerDirectory class, which belongs to the Account Management bounded context. This is a binary dependency that requires in-process communication. You can see the code demonstrating this in Listing 13-1.

清单 13-1 展示了被调用的FollowerDirectory.FindUsersFollowers()方法。这个方法存在问题，它耦合了两个有界上下文。我们将用一个跨网络的类似名称的 RPC 来替换它，从而消除 Discovery 和 Account Management 有界上下文之间有问题的二进制依赖关系。

Listing 13-1 shows the FollowerDirectory.FindUsersFollowers() method being called. This is the problematic method that couples two bounded contexts. It is going to be replaced with a similarly named RPC across the network, thereby removing the problematic binary dependency between the Discovery and Account Management bounded contexts.

图 13.1还提供了您将要实现的用例的更多背景信息。您可以看到，当用户登录并到达其主页时，该用例会被触发。此时，业务需求是让用户看到他们可能想要关注的推荐用户列表。这对业务至关重要，因为它允许用户发现其他用户和热门话题，从而吸引他们继续访问网站。一个由业务人员和开发人员组成的完整团队致力于帮助用户发现内容。这个团队被称为发现团队，而发现限界上下文代表了其领域范围。

Figure 13.1 also provides further background for the use case you are going to implement. You can see that the use case is triggered when a user logs in and arrives at her home page. When this happens, the business requirement is for users to see a list of recommended users whom they might want to follow. This is important to the business because it allows users to discover other users and hot topics so they continue to return to the site. An entire team of business people and developers is focused on helping users discover content. The team is known as the Discovery team, and the Discovery bounded context represents its area of the domain.

使用 WCF 和 SOAP 实现 HTTP 上的 RPC

使用 .NET 的 Windows Communication Foundation (WCF) 时，使用 SOAP 集成两个有界上下文最初可能非常快速且相对容易。在后续章节中，当您开始实现图 13.1所示的用例时，您将亲身体验到这一点。

Integrating two bounded contexts using SOAP can initially be quite fast and relatively easy when using .NET’s Windows Communication Foundation (WCF). You’ll see this firsthand as you start to implement the use case shown in Figure 13.1 in the following sections.

创建 WCF 服务

首先，您需要创建一个空白的 Visual Studio 解决方案，用于存放所有有界上下文（在本 SOAP 示例中）。您可以将此解决方案命名为PPPDDD.SOAP.SocialMedia。需要创建的第一个有界上下文是 Account Management 。要添加 Account Management 有界上下文，您需要在项目中添加一个名为AccountManagement的新 WCF 服务应用程序，如图 13.2所示。

To get started, you need to create a blank Visual Studio solution that will be home to all the bounded contexts (in this SOAP example). You can call this solution PPPDDD.SOAP.SocialMedia. The first bounded context to be created is Account Management. To add the Account Management bounded context, you need to add a new WCF Service Application to the project called AccountManagement, as shown in Figure 13.2.

在旧的单体应用程序中，如清单 13-1 所示，有一个名为FollowerDirectory的类，它有一个名为FindUsersFollowers的方法。为了将这个进行 RPC 调用时，您只需在项目根目录下添加一个名为FollowerDirectory的 WCF 服务即可。然后，您可以使用 WCF 服务契约来声明您的 RPC，如下一节所示。

In the old monolithic application, as you saw in Listing 13-1, there was a class called FollowerDirectory that had a method called FindUsersFollowers. To turn this into an RPC call, you can simply add a WCF Service to the root of the project called FollowerDirectory. Then you can use WCF Service contracts to declare your RPCs, as shown in the next section.

服务合同

添加 WCF 服务后，项目根目录中会添加两个文件：FollowerDirectory.svc.cs和IFollowerDirectory.cs。后者是 Visual Studio 用于生成公共 SOAP 契约（使用 Web 服务描述语言，即 WSDL）的文件。前者是实现；您的自定义代码将放在其中，并在运行时进行 RPC 调用时运行。您很快就会看到它的实际效果，所以如果感觉不太明白也不用担心。

After you’ve added the WCF Service, two files are added to the root of the project: FollowerDirectory.svc.cs and IFollowerDirectory.cs. The latter is what Visual Studio uses to generate a public SOAP contract (using the Web Service Description Language, or WSDL). The former is the implementation; your custom code goes in it and is run when RPC calls are made at run time. You see this in action shortly, so don’t worry if it doesn’t make perfect sense.

WCF 有两个注解：ServiceContract和OperationContract。ServiceContract添加到接口中，表示该类包含可在网络上以 RPC 形式调用的方法。OperationContract则表示用ServiceContract修饰的接口上的哪些方法是 RPC。因此，要创建FollowerDirectory.FindUsersFollowers() RPC 调用，应该应用这两个属性，如清单 13-2 所示。

WCF has two annotations: ServiceContract and OperationContract. ServiceContract is added to an interface to signify that the class contains methods that can be called as RPCs across the network. OperationContract then signifies which methods on an interface decorated with ServiceContract are the RPCs. Therefore, to create the FollowerDirectory.FindUsersFollowers() RPC call, you should apply those two attributes, as shown in Listing 13-2.

清单 13-2 是 Visual Studio 和 WCF 生成 RPC 基础结构所需的全部内容。稍后您将看到 Visual Studio 会在 Web 服务的客户端上自动生成这些类的代理。这种“免费网络”正是 WCF 和 SOAP 如此吸引人的原因。

Listing 13-2 is all that Visual Studio and WCF requires from you to be able to generate the RPC infrastructure. You’ll see later that Visual Studio automatically generates proxies of these classes on clients of the web service. This “networking for free” is what makes WCF and SOAP so appealing to many.

在你的服务运行之前，你需要在FollowerDirectory.svc.cs文件中提供一个实现。你可以在清单 13-3 中看到一个基本实现，它在内存中生成一些虚拟的 Follower 并返回它们。你可以使用此实现更新你的FollowerDirectory。

Before your service will work, you need to provide an implementation in the FollowerDirectory.svc.cs file. You can see a basic implementation in Listing 13-3 that generates a few dummy Followers in-memory and returns them. You can update your FollowerDirectory with this implementation.

测试 WCF 服务

现在，您可以测试是否真的可以通过网络以 RPC 方式调用FindUsersFollowers()了。Visual Studio 提供的测试客户端让测试变得简单。要运行测试客户端，请在解决方案资源管理器中选中FollowerDirectory.svc项（而不是FollowerDirectory.sv.cs ），然后按 F5。您将看到如图 13.3所示的测试客户端。

You’re now in a position to test that you really can call FindUsersFollowers()over the network as an RPC. Visual Studio makes this easy with the test client it provides. To run the test client, highlight the FollowerDirectory.svc item in the Solution Explorer (not FollowerDirectory.sv.cs) and press F5. You will then see the test client as illustrated in Figure 13.3.

要测试您的新服务，只需在左侧资源管理器窗格中双击其名称（FindUsersFollowers ），然后在右侧窗格中accountId 行的Value列中输入一个值。完成后，如果您点击 Invoke 按钮，您的FindUsersFollowers RPC 将通过网络执行，结果将显示在右侧窗格的下半部分，如图13.4所示。

To test your new service, just double-click its name (FindUsersFollowers) in the left-hand Explorer pane, and then enter a value in the Value column for the row accountId in the right pane. After doing that, if you click the Invoke button, your FindUsersFollowers RPC will be carried out over the network, and the results will be displayed in the lower half of the right pane, as shown in Figure 13.4.

如果您想查看数据是如何在网络上传输的，可以点击右侧窗格底部的“XML”选项卡。这样，您就可以看到原始的 SOAP：

If you want to see how the data was transmitted across the network, you can click on the XML tab at the bottom of the right pane. By doing that, you see the raw SOAP:

<s:Envelope xmlns:s="http://schemas.xmlsoap.org/soap/envelope/">
  <s:Header />
  <s:Body>
    <FindUsersFollowersResponse>
      <FindUsersFollowersResult
xmlns:a="http://schemas.datacontract.org/2004/07/
AccountManagement" xmlns:i="http://www.w3.org/2001/
XMLSchema-instance">
        <a:Follower>
          <a:FollowerId>follower_0</a:FollowerId>
          <a:FollowerName>happy follower 0</a:FollowerName>
          <a:SocialTags
xmlns:b="http://schemas.microsoft.com/2003/10/
Serialization/Arrays">
            <b:string>programming</b:string>
            <b:string>DDD</b:string>
            <b:string>Psychology</b:string>
          </a:SocialTags>
        </a:Follower>
        <a:Follower>
        ...

<s:Envelope xmlns:s="http://schemas.xmlsoap.org/soap/envelope/">
  <s:Header />
  <s:Body>
    <FindUsersFollowersResponse>
      <FindUsersFollowersResult
xmlns:a="http://schemas.datacontract.org/2004/07/
AccountManagement" xmlns:i="http://www.w3.org/2001/
XMLSchema-instance">
        <a:Follower>
          <a:FollowerId>follower_0</a:FollowerId>
          <a:FollowerName>happy follower 0</a:FollowerName>
          <a:SocialTags
xmlns:b="http://schemas.microsoft.com/2003/10/
Serialization/Arrays">
            <b:string>programming</b:string>
            <b:string>DDD</b:string>
            <b:string>Psychology</b:string>
          </a:SocialTags>
        </a:Follower>
        <a:Follower>
        ...

创建 WCF 服务客户端

现在您将看到 WCF、SOAP 和 Visual Studio 的组合为您完成了许多繁琐的工作。您将首先创建 Discovery 限界上下文项目，然后了解如何通过将 Discovery 限界上下文指向 Account Management 限界上下文的统一资源定位符 (URL) 来开始对 Account Management 限界上下文进行 RPC 调用。

You’re now about to see that the WCF, SOAP, and Visual Studio combination does a lot of the hard work for you. You’ll first create the Discovery bounded context project, and you’ll then see how you can start making RPC calls to the Account Management bounded context just by pointing the Discovery bounded context to the uniform resource locator (URL) of the Account Management bounded context.

首先，您需要向解决方案中添加一个名为Discovery 的新 WCF 服务应用程序，该应用程序代表 Discovery 限界上下文。然后，您需要在 Discovery 限界上下文中添加一个名为 Recommender 的 WCF 服务。Recommender提供网站用来获取推荐用户列表的 Web 服务。快速参考图 13.1中的设计可能会有所帮助。

To begin, you need to add a new WCF Service Application to the solution called Discovery that represents the Discovery bounded context. Inside the Discovery bounded context, you then need to add a WCF Service called Recommender. Recommender provides the web services that the website uses to get the list of recommended users. You may find it helpful to quickly refer to the design in Figure 13.1.

推荐器有两个职责。首先，它为客户端提供请求推荐的 API。为了履行这一职责，它会向账户管理限界上下文发起 RPC 调用，以获取账户的关注者。要实现这一点，您需要运行账户管理项目。（在解决方案资源管理器中选中它，然后按 Ctrl+F5。）然后，您可以通过在 Web 浏览器中直接访问http://localhost:3100/FollowerDirectory.svc来测试它是否正在运行。如果页面标题为“FollowerDirectory Service”，则表示一切正常。

Recommender has two responsibilities. First, it provides the API for clients to request recommendations. To fulfill that responsibility, it makes the RPC to the Account Management bounded context get an Account’s followers. To implement that, you need to have the Account Management project running. (Highlight it in the Solution Explorer and press Ctrl+F5.) You can then test that it is running by directly accessing it in a web browser at http://localhost:3100/FollowerDirectory.svc. If the page has the heading “FollowerDirectory Service,” things are working.

接下来，您需要将 URL 传递给 Visual Studio，以便它生成代理类。在解决方案资源管理器中，右键单击Discovery 项目的“引用”节点，然后选择“添加服务引用”，即可将 URL 粘贴到“地址”字段中。剩下的就是将“命名空间”（位于“添加服务引用”对话框的底部）更改为AccountManagement，然后单击“执行”。您的屏幕之后应该类似于图 13.5所示，其中展开了FollowerDirectory节点，并显示了它所识别的 Web 服务。确认无误后，单击“确定”。

Next, you need to pass the URL to Visual Studio so it can generate the proxy classes. If you right-click on the References node for the Discovery project in the Solution Explorer and select Add Service Reference, the URL can be pasted into the Address field. All that’s left is to change the Namespace (at the bottom of the Add Service Reference dialog) to AccountManagement and click Go. Your screen should then resemble Figure 13.5, which shows the expanded FollowerDirectory node revealing the web service it has identified. Once you’re happy, you can click OK.

要查看生成的代理类，可以检查添加到“服务引用”文件夹中的AccountManagement项。图 13.6展示了生成的代理类。这些类稍后将在 Discovery 限界上下文中实例化，并调用其方法（通过 SOAP/HTTP）来调用与 Account Management 限界上下文相关的 RPC。

To see the generated proxy classes, you can inspect the AccountManagement item that was added to the Service References folder. Figure 13.6 shows the generated proxy classes. These are the classes that you will shortly instantiate in the Discovery bounded context and call methods on to invoke RPCs across to the Account Management bounded context (via SOAP/HTTP).

最后一步是构建 Recommender Web 服务，使生成的代理类能够正常工作。清单 13-4 和清单 13-5 展示了IRecommender和Recommender的基本实现，它们足以演示 RPC 调用。您需要将它们添加到Discovery项目中。

The last step is to build the Recommender web service that puts the generated proxy classes to work. Listing 13-4 and Listing 13-5 show a basic implementation of the IRecommender and Recommender that do just enough to demonstrate the RPC call. You need to add these to your Discovery project.

在清单 13-5 中，创建了AccountManagement.FollowerDirectoryClient的一个实例。它是 Visual Studio 在添加服务引用时生成的代理类。当调用它的FindUsersFollowers()方法时，它会通过网络触发一个 RPC，并调用您在帐户管理限界上下文中添加的代码。这里的主要要点是 WCF 和 Visual Studio 负责所有与网络相关的管道。即使不涉及网络，您添加的大多数代码看起来也非常相似。

In Listing 13-5, an instance of AccountManagement.FollowerDirectoryClient is created. It is a proxy class that Visual Studio generated when adding the Service Reference. When its FindUsersFollowers() method is called, it fires an RPC across the network and calls into the code you added in the Account Management bounded context. The main takeaway here is that WCF and Visual Studio took care of all the network-related plumbing. Most of the code you added would look very similar even if there was no network involved.

您可以通过将两个项目设置为启动来测试一切是否正常（如上一章所示，在解决方案资源管理器中右键单击解决方案并选择“设置启动项目”），然后在解决方案资源管理器中的Recommender.svc文件上按 F5 键。WCF 测试客户端会再次弹出，这次您需要调用GetRecommendedUsers() ，如图13.7所示。

You can test that everything is successfully working by setting both projects to start up (as shown in the previous chapter by right-clicking the solution in the Solution Explorer and choosing Set Startup Projects) and then pressing F5 on the Recommender.svc in the Solution Explorer. The WCF test client pops up again, and this time you need to invoke GetRecommendedUsers(), as demonstrated in Figure 13.7.

图 13.7中 RPC 调用的结果是由您创建的 Web 服务返回的硬编码数据。这表明两个有界上下文之间的 RPC 调用已成功完成。总而言之，本示例的目标——即在不产生二进制依赖的情况下集成账户管理和发现有界上下文——已经实现。

The result of the RPC call in Figure 13.7 is the hard-coded data that is returned by the web service you created. This indicates that the RPC call between the two bounded contexts successfully occurred. Conclusively, this example’s aim of integrating the Account Management and Discovery bounded contexts without a binary dependency has now been achieved.

肥皂的衰落

虽然目前有很多公共的 SOAP API，但现在已经不再使用 SOAP 构建新的 API。SOAP 的一大痛点是其消息格式的复杂性和冗长性。您之前已经略微了解过这一点。人们批评不必要的复杂性，并且经常引用 SOAP 作为不必要复杂性的完美例子。因此，您应该谨慎公开 SOAP API，但如果内部使用 SOAP 符合您的需求，则不必过于担心。

Although there are many existing public SOAP APIs, new APIs just aren’t being built with SOAP anymore. One of SOAP’s big pain points is the complexity and verbosity of its message format, which you saw a glimpse of earlier. People are critical of needless complexity, and they often cite SOAP as a perfect example of unnecessary complexity. Accordingly, you should be careful about exposing public SOAP APIs, but you shouldn’t feel too concerned about using SOAP internally if it suits your needs.

如今，RPC over HTTP 的主流做法是使用轻量级的纯 XML 或 JSON 负载。下一节将使用 ASP.NET Web API 展示此类示例。

The modern preference for RPC over HTTP is to use lightweight, plain XML or JSON payloads. The next section shows examples of this using ASP.NET Web API.

纯 XML 或 JSON：RPC 的现代方法

Plain XML or JSON: The Modern Approach to RPC

为了了解如何通过 HTTP 集成，避免 SOAP 格式的复杂性和冗长，本节将使用相对轻量级的 JSON 重新创建社交媒体 SOAP 集成。以下是之前显示的 SOAP 负载的 JSON 版本。您可以回过头来比较一下，以充分体会 JSON 的简洁性。

To see how you can integrate over HTTP without the complexity and verbosity of the SOAP format, in this section, you re-create the social media SOAP integration instead using the relatively lightweight JSON. The following is the JSON version of the SOAP payload shown earlier. You may want to go back and compare to fully appreciate how the JSON is far more compact.

{
    "followers": [
        {
          "accountId":"34djdlfjk2j2",
          "socialTags": [
              "ddd","soa","tdd","kanban"
           ]
        },
        ...
    ]
}

{
    "followers": [
        {
          "accountId":"34djdlfjk2j2",
          "socialTags": [
              "ddd","soa","tdd","kanban"
           ]
        },
        ...
    ]
}

使用 ASP.NET Web API 通过 JSON 实现 HTTP 上的 RPC

ASP.NET Web API 是微软最新的 Web 服务创建框架。稍后您将了解它如何成为构建 RESTful API 的理想选择。但现在，您将首先了解它如何简化 JSON RPC API 的构建。首先，您需要一个名为PPPDDD.JSON.SocialMedia 的新空白 Visual Studio 解决方案。此解决方案需要填充一个名为AccountManagement的 ASP.NET Web 应用程序项目。在创建项目的过程中，您需要选择“空”模板并选中“Web API”复选框。创建完成后，您需要将项目配置为始终从端口 3200 启动。

The ASP.NET Web API is Microsoft’s latest framework for creating web services. Later you will see how it can be a good choice for building RESTful APIs. But for now you’ll see how it can make life easy when building JSON RPC APIs. As a starting point, you need a new blank Visual Studio solution called PPPDDD.JSON.SocialMedia. This solution needs to be populated with an ASP.NET Web Application project called AccountManagement. As you go through the creation process for the project, you need to select the Empty template and check the Web API check box. Once it’s created, you need to configure the project to always start on port 3200.

控制器包含向 Web API 发出 Web 请求时将运行的代码。您可以将控制器视为从通用语言 (UL) 表达领域概念的机会，但在将领域逻辑放入控制器时应谨慎。一些开发人员将控制器概念化为应用服务。

Controllers contain the code that will be run when web requests are made to your Web API. You can see controllers as an opportunity to express domain concepts from the ubiquitous language (UL), although you should be careful about putting domain logic in them. Some developers conceptualize controllers as Application Services.

要开始此示例，您需要在项目根目录中的Controllers文件夹中添加一个名为FollowerDirectoryController的类；Web API 要求将控制器放在此文件夹中。FollowerDirectoryController的代码如清单 13-6 所示。

To start with this example, you need to add a class called FollowerDirectoryController to the Controllers folder in the root of the project; Web API requires that controllers be placed in this folder. The code for FollowerDirectoryController is shown in Listing 13-6.

为了演示目的，清单 13-6 中的FollowerDirectoryController返回一个硬编码的Follower列表（以 JSON 格式）。在实际应用程序中，此类可能会执行数据库查找或 API 调用来获取所需的关注者信息。

For demonstrative purposes, the FollowerDirectoryController in Listing 13-6 returns a list of hard-coded Followers (as JSON). In a real application, this class would likely perform database lookups or API calls to get the required follower information.

启动应用程序（按 F5 键）后，您可以通过在浏览器中访问它来测试新的 Web 服务。使用 Web API 的默认约定，可以通过http://localhost:3200/api/followerdirectory/getusersfollowers?accountId=123访问它，其中accountId参数的值是变量。（在本例中，它可以是任意值。）图 13.8展示了一个从浏览器访问 API 并查看 JSON 响应的示例。

After starting the application (by pressing F5), you can test the new web service by hitting it in the browser. Using Web API’s default conventions, it is accessible at http://localhost:3200/api/followerdirectory/getusersfollowers?accountId=123, where the value for the accountId parameter is variable. (It can be anything in this example.) Figure 13.8 shows an example of hitting the API from a browser and viewing the JSON response.

可以看出，与 SOAP 和 WCF 相比，这种方法需要额外做一些工作来设置控制器，但通过网络发送的数据更加简洁明了，更容易理解正在发生的事情。这对于调试问题来说也是一个优势。

You can see with this approach that you had to do a tiny bit of extra work setting up the controller compared to SOAP and WCF, but the data sent across the wire is so much cleaner and lighter that it’s easy to understand what is happening. This is also a bonus when it comes to debugging problems.

由于缺乏 SOAP 提供的丰富元数据，因此无法为纯 JSON API 自动生成代理类。不过，正如您现在将看到的，这仍然不需要太多额外的工作。

Lacking the richness of meta data provided by SOAP, it is not possible to automatically generate proxy classes for a plain JSON API. It still doesn’t have to be a lot of extra work, though, as you’ll now see.

要创建 JSON API 的客户端，需要添加一个名为Discovery的新 ASP.NET Web 应用程序来表示 Discovery 有界上下文。在Discovery项目内部，需要在Controllers文件夹中添加一个名为RecommenderController的类。该类的代码如清单 13-7 所示。为了进行编译，需要在 Nuget 包管理器控制台中运行以下命令来安装HttpClient和ServiceStack.Text ：

To create a client of your JSON API, you need to add a new ASP.NET Web Application, called Discovery, to represent the Discovery bounded context. Inside the Discovery project, you need to add a class called RecommenderController in the Controllers folder. The code for this class is shown in Listing 13-7. For it to compile, you need to install HttpClient and ServiceStack.Text by running the following commands in the Nuget Package Manager Console:

Install-Package Microsoft.AspNet.WebApi.Client -Project Discovery
Install-Package ServiceStack.Text -Project Discovery

Install-Package Microsoft.AspNet.WebApi.Client -Project Discovery
Install-Package ServiceStack.Text -Project Discovery

如清单 13-7 所示，此实现的逻辑与前一个示例中的 WCF 方法类似。但是，使用此解决方案，您必须手动完成发出 HTTP 请求和解析响应的工作。不过，正如您所见，微软和社区提供了功能丰富的库，可以为您完成许多繁重的工作。

As Listing 13-7 shows, the logic for this implementation is similar to the WCF approach in the previous example. However, with this solution, you have to do the manual work of making the HTTP request and parsing the response yourself. As you can see, though, there are feature-rich libraries, provided by Microsoft and the community, that do a lot of the laborious work for you.

为了测试一切是否按预期运行，您需要将两个项目都设置为启动项目（如前面的示例所示）。然后，您需要导航到刚刚创建的GetRecommendedUsers API 的 URL。该 URL 为 http://localhost:{port}/api/recommender/getrecommendedusers?accountId=123，具体取决于 Discovery 限界上下文在您计算机上使用的端口。在解决方案中按下 F5 键时，会自动弹出一个浏览器，告知您端口号（或者，您也可以手动指定端口，如本章前面所示）。

To test that everything works as intended, you need to set both projects as start-up projects (as shown in previous examples). You then need to navigate to the URL of the GetRecommendedUsers API you just created. The URL is http://localhost:{port}/api/recommender/getrecommendedusers?accountId=123 depending on which port the Discovery bounded context is using on your machine. A browser automatically pops up informing you of the port number when you press F5 inside the solution (or you can manually specify a port, as shown earlier in this chapter).

选择 RPC 风格

Choosing a Flavor of RPC

刚刚演示了使用两种常见方法将有界上下文与 RPC over HTTP 集成。使用 WCF 和 SOAP，您可以向领域模型添加一些属性，它就会突然变成一个分布式系统，摆脱有界上下文之间的二进制依赖。反过来，这使得团队更加独立，不必担心破坏其他有界上下文。然而，SOAP 的一个问题是格式复杂且冗长；在许多情况下，RPC 仅用于简单的集成，因此这似乎不太合理。这就是为什么纯 XML 或 JSON 如今更受欢迎的原因。

Integrating bounded contexts with RPC over HTTP was just demonstrated using two common approaches. With WCF and SOAP you can add a few attributes to your domain model and suddenly it becomes a distributed system free from binary dependencies between bounded contexts. In turn, this allows teams to be more independent and not have to worry about breaking other bounded contexts. One problem with SOAP, though, is that the format is complex and verbose; in many cases, RPC is used for simple integrations, so this doesn’t seem logical. This is why plain XML or JSON is the more popular choice today.

然而，这两种方案都存在第 11 章中提到的 RPC 固有缺陷。首先，它们可能更难有效扩展。回顾图 13.1中的图表，假设业务部门即将提出一个请求，要求提高推荐关注者在屏幕上显示的速度。为了提升整体性能，发现限界上下文和账户管理限界上下文可能都需要扩展。如果 RPC 链跨越三个限界上下文，那么由于时间耦合，可能需要扩展这三个限界上下文。

Both options, however, have the flaws inherent to RPC that were mentioned in Chapter 11. First, they can be harder to scale efficiently. Looking back at the diagram in Figure 13.1, consider a forthcoming request from the business to improve the speed at which recommended followers are displayed onscreen. Both the Discovery bounded context and the Account Management bounded context may need to be scaled to provide an overall performance improvement. If the chain or RPCs spanned three bounded contexts, then three bounded contexts may need to be scaled due to the temporal coupling.

在容错方面，也存在一些令人担忧的迹象。如果账户管理有界上下文发生故障，发现有界上下文也会发生故障，因为它无法通过 RPC 跨域获取关注者。同样，这是由于时间耦合造成的。

In terms of fault tolerance, there are also worrying signs. If the Account Management bounded context goes down, the Discovery bounded context also goes down because it cannot RPC across and get the followers. Again, this is due to the temporal coupling.

你可能觉得需要在集成 HTTP 以实现松散的平台耦合，和使用 NServiceBus 等消息传递框架构建可扩展、容错的系统之间做出选择。但这完全不是事实。本章的下一部分将展示如何将响应式编程的原则与 REST 相结合，从而实现消息传递系统的可扩展性和容错性以及 HTTP 的松散平台耦合。

It may seem like you need to choose between integrating with HTTP for loose platform coupling and having a scalable, fault-tolerant system that uses a messaging framework like NServiceBus. But that’s completely untrue. The next section of this chapter shows that you can have the scalability and fault tolerance of a messaging system and the loose platform coupling of HTTP by combining the principles of reactive programming with REST.

揭秘 REST

Demystifying REST

REST 由 Roy Fielding 首次提出。他基于互联网成功的原则，创建了 REST 这一架构风格。REST 包含许多基本概念，包括资源和超媒体，它们为可演进的客户端和服务器提供了平台。

REST was introduced to the world by Roy Fielding. He created REST as an architectural style based on the principles that make the Internet so successful. REST has a number of fundamental concepts, including resources and hypermedia, which provide the platform for evolvable clients and servers.

用于有界上下文集成的 REST

REST for Bounded Context Integration

本章剩余内容的背景是对前面 RPC 示例的重新设计。凭借一些杀手级新功能和病毒式营销活动，这家虚构的社交媒体初创公司的用户注册量再次呈指数级增长。该公司希望通过增加高级账户并将其推广给普通用户来获利。高级账户是公司在社交媒体网站上吸引粉丝的一种方式，从而通过提升品牌忠诚度获利。

The context for the remainder of this chapter is a redesign of the RPC examples earlier in the chapter. With some killer new features and viral marketing campaigns, user sign-ups for the fictitious social media start-up have again increased exponentially. The business wants to cash in on its success by adding premium accounts that are promoted to regular users. Premium accounts are a way for companies to gain followers on the social media website so they can profit from enhanced brand loyalty.

不幸的是，正如很多情况一样，基于 RPC 的集成扩展性不佳。它最初因其上市时间优势而被视为完美的选择，但现在却因为开发人员花费过多时间进行应急处理而导致功能无法交付。因此，在添加新功能之前，您需要先稳定系统，以支持业务的快速增长。

Unfortunately, as happens on many occasions, the RPC-based integration is not scaling well. It was the perfect choice initially for its time-to-market advantages but is now preventing features from being delivered because developers spend too long fire-fighting. So before you can add new features, you need to stabilize the system to support the rapid growth of the business.

新版系统基于事件驱动架构。有趣的是，该系统并未采用上一章介绍的通用消息总线方法，而是使用了 REST 和 HTTP，从而避免了系统生命周期内的技术/供应商锁定。

This new version of the system is based on an event-driven architecture. Interestingly, though, instead of taking the common message bus approach (as per the previous chapter), this system uses REST and HTTP to preclude technology/vendor lock-in for the lifetime of the system.

为 REST 而设计

Designing for REST

正如上一章所述，少量的设计可以创建共同的愿景，并加深对正在构建的系统如何满足其功能性和非功能性需求的理解。设计使用 REST 进行集成的系统的一些步骤与设计消息传递系统的步骤有所不同。但大多数步骤是相似的，包括第一步：从领域开始。

As suggested in the previous chapter, a small amount of design can create a shared vision and a deeper understanding of how the system being built addresses its functional and nonfunctional requirements. Some steps for designing a system that uses REST for integration will differ from those used to design a messaging system. Mostly the steps will be similar, though, including the first step: start with the domain.

领域驱动设计

使用 UL 在一组草图中表达业务策略，再次成为设计系统的重要第一步。在确定技术解决方案之前，弄清楚需要解决的问题以及需要建模的领域流程几乎总是有意义的。

Expressing business policies, using the UL, in a set of sketches is again a useful first step in designing a system. It nearly always makes sense to work out what problem you need to solve and what domain processes you need to model before you decide on a technical solution.

图 13.9是一个组件图，展示了“推荐账户”用例的全新事件驱动设计。与上一章中的消息传递解决方案一样，它专注于领域命令和事件。实际上，这种设计也可以用于消息传递系统，因为该图关注的是业务用例期间的消息流，并且与技术选择无关。

Figure 13.9 is a component diagram illustrating the new event-driven design of the Recommended Accounts use case. As with the messaging solution in the previous chapter, it focuses on domain commands and events. In fact, this design could be for a messaging system, because the diagram focuses on the flow of messages during the business use case and is independent of technology choices.

在图 13.9中，您可以看到两个关键的领域事件。首先是“开始关注”。在整个公司，每位员工都知道，“开始关注”领域事件发生在一个帐户开始关注另一个帐户时。这是 UL 的一部分，也是公司的核心概念之一。显示的另一个领域事件是“已识别高级推荐”。这也是 UL 的一部分，表示发现限界上下文已识别高级帐户的事件普通账户可能愿意关注。这是一个至关重要的域名概念，因为向普通用户推广高级账户是新商业模式的核心。

In Figure 13.9, you can see two key domain events. First, there is Began Following. Throughout the company, every member of staff understands that a Began Following domain event occurs when one account starts following another. This is part of the UL and one of the core concepts of the business. The other domain event shown is Premium Recommendations Identified. This is also part of the UL, representing occurrences where the Discovery bounded context has identified a premium account that a regular account may like to follow. This is a crucial domain concept, because promoting premium accounts to regular users is central to the new business model.

面向服务架构

第 11 章向您展示了遵循 SOA 原则可以实现松耦合的有界上下文。反过来，这可以为高效团队提供平台。SOA 的原则与技术无关，因此您可以在使用 HTTP 构建系统时应用它们。

Chapter 11 showed you that following the principles of SOA can lead to loosely coupled bounded contexts. In turn, this can provide the platform for high-performing teams. SOA’s principles are technology agnostic, so you can apply them when building systems with HTTP.

通过隔离每个团队拥有的有界上下文，松耦合变得触手可及。每个团队都可以根据其业务优先级自由开发功能，避免跨团队干扰或依赖。与消息传递相比，使用基于 HTTP 的 SOA 的唯一区别在于，团队之间的契约不再是代码中的类，而是 HTTP 请求和响应的格式。接下来的示例将充分展示这一点。

By isolating bounded contexts each owned by a single team, loose coupling is within reach. Each team is free to develop its features in line with its business priorities, free of cross-team distractions or dependencies. All that changes when using SOA with HTTP compared to messaging is that the contract between teams is no longer classes in code, but the format of HTTP requests and responses. Upcoming examples fully demonstrate this.

事件驱动和反应式

您在第 11 章和第 12 章中看到，基于响应式原则的异步消息传递是构建容错可扩展系统的推荐方法。与 REST 和 HTTP 集成时也是如此。您可能知道，HTTP 本身并不支持发布/订阅模式，因此，无法像消息总线那样在事件发生时将其推送给订阅者。相反，使用 REST，客户端可以轮询更改。轮询通常在扩展方面存在负面影响，但利用 HTTP 的缓存约定可以解决这个问题。

You saw in Chapters 11 and 12 that asynchronous messaging, based on reactive principles, was the recommendation for building fault-tolerant scalable systems. This is also the case when integrating with REST and HTTP. As you are probably aware, HTTP doesn’t inherently support publish/subscribe, so there’s no way to push out events to subscribers as they occur like you can with a message bus. Instead, with REST, clients can poll for changes. Polling generally has negative connotations in terms of scaling, but utilization of HTTP’s caching conventions can negate this problem.

图 13.10是本章剩余部分将构建的全新反应式 RESTful 社交媒体系统的容器图。请注意，它与消息传递系统有一些相似之处：每个组件都很小，因此可以根据业务需求独立扩展；有界上下文不共享数据库等依赖项。此外，由于 HTTP 的存在，每个团队都可以在其有界上下文中使用任何自己喜欢的技术（这在上一章中比较难实现）。这些特性支持可扩展性、容错性和开发速度。

Figure 13.10 is the containers diagram for the new Reactive, RESTful social media system that will be built in the remainder of this chapter. Note how there are some similarities to a messaging system: each component is small so that it can be scaled independently according to business needs; bounded contexts do not share dependencies such as databases. Additionally, thanks to HTTP, each team can use any technologies it prefers within its bounded contexts (which was more difficult to achieve in the previous chapter). These traits support scalability, fault tolerance, and development velocity.

可扩展性的一个重要设计考虑因素是项目的粒度。对于 HTTP API，您可以将所有端点放在一个项目中，但这样一来，您就无法轻松地根据它们各自的可扩展性需求独立部署它们。本章中较为宽泛的建议是，一开始就为每个资源创建一个项目。图 13.10中的示例是入口点资源和帐户资源的独立项目。

An important design consideration for scalability is the granularity of projects. For your HTTP APIs, you could put all your endpoints in one project, but then you couldn’t easily deploy them independently based on their individual scalability needs. The loose recommendation in this chapter is to start with one project per resource. Examples of this in Figure 13.10 are the stand-alone projects for the entry point resource and the Accounts resource.

当您拥有嵌套资源时，有时您可能还需要考虑将它们移入其自己的项目。这样做的主要因素通常是，额外项目的复杂性与独立扩展 API 的能力之间存在矛盾。如果特定用例对可扩展性有很高的要求，您甚至可能希望将单个请求处理程序移入其自己的项目。

When you have nested resources, you may also want to consider moving them into their own project sometimes. The main factors for doing so will usually be complexity of having extra projects traded off against the ability to scale APIs independently. You may even want to move individual request handlers into their own project if specific use cases have demanding scalability requirements.

HTTP 和超媒体

超媒体是 REST 的基础，因为它使得客户端和服务器能够彼此独立地发展。因此，在开始构建系统之前，预先考虑一下超媒体的契约会很有帮助。（你仍然可以在构建过程中不断迭代。）设计 REST 工作流的一个好方法是使用如图 13.11所示的序列图，该图演示了事件驱动的“添加关注者”用例。

Hypermedia is fundamental to REST because it is the factor that enables clients and servers to evolve independently of one another. So it can be useful to think a little about the hypermedia contracts up front before you start to build the system. (You can still iterate as you go along.) A good way to design REST workflows is to use sequence diagrams like the one shown in Figure 13.11 that demonstrates the event-driven Add Follower use case.

如您所见，客户端仅与入口点 URI 耦合。从那里，它们通过响应中提供的超媒体链接向其他服务发出请求。例如，客户端想要在帐户管理中启动“添加关注者”用例（类似于域命令）。有界上下文仅与入口点资源的 URI（ /accountmanagement）耦合。从那时起，客户端只需跟随超媒体中的链接（以 HTTP 响应的形式返回），直到到达关注者资源。

As you can see, clients are only coupled to the entry point URI. From there, they make requests to other services by following hypermedia links provided in responses. For instance, clients wanting to initiate the Add Follower use case (akin to a domain command) on the Account Management bounded context are only coupled to the URI of the entry point resource—/accountmanagement. From then on, clients merely follow links in the hypermedia, returned as HTTP responses, until the Followers resource is reached.

在图 13.10所示的容器图中，每个 HTTP 端点旁边都标明了其内容类型。大多数都显示为 application/hal+json。HAL 代表超文本应用程序语言；它本质上就是众所周知的现有内容类型（XML 和 JSON），并带有表示超媒体链接的约定。您可以在 Mike Kelly 的博客 ( http://stateless.co/hal_specification.html ) 上深入了解 HAL 标准。本章其余部分的示例使用 application/hal+json，因此您只需阅读本章即可学习基础知识。

In the containers diagram shown in Figure 13.10, there is an indication next to each HTTP endpoint of its content type. Most of them show application/hal+json. HAL stands for Hypertext Application Language; it is essentially just well-known existing content types—XML and JSON—with conventions for representing hypermedia links. You can learn about the HAL standard in depth on Mike Kelly’s blog (http://stateless.co/hal_specification.html). The examples in the remainder of this chapter use application/hal+json, so you will still learn the basics just by reading this chapter.

容器图上显示的另一种内容类型是 application/atom+xml，它表示 Atom。Atom 是生成 RSS 源的通用标准，因此非常适合表示事件列表。这正是帐户管理限界上下文使用它的方式——表示已发生的“开始关注”事件列表。

Another content type shown on the containers diagram is application/atom+xml, which denotes Atom. Atom is a common standard for producing RSS feeds and thus is a great fit for representing lists of events. This is precisely how it is used by the Account Management bounded context—to represent the list of Began Following events that have occurred.

本章将使用 Atom 作为事件源，这是构建基于 REST 的事件驱动分布式系统的主要基石。不一定非要使用 Atom，但 Atom 的流行度绝对值得考虑。

Using Atom as a feed of events is the main building block for building event-driven distributed systems with REST in this chapter. It doesn’t have to be Atom, but Atom’s popularity means you should definitely consider it.

图 13.12展示了一个轮询 Atom 提要以获取领域事件的示例。该图展示了轮询 Began Following Atom 提要所涉及的 HTTP 消息流，您将在本章后面构建该提要。

An example of polling an Atom feed for domain events is shown in Figure 13.12. This diagram shows the flow of HTTP messages involved for polling the Began Following Atom feed that you will build later in this chapter.

使用 ASP.NET Web API 构建事件驱动的 REST 系统

Building Event-Driven REST Systems with ASP.NET Web API

现在您已经了解了所有理论知识，是时候开始构建 RESTful 风格的、事件驱动的社交媒体应用了。为了保持示例简洁并专注于基本模式，您将只构建账户管理有界上下文和部分发现有界上下文。通过这些示例，您将学到足够的知识，可以在您自己的项目中运用这些概念。

Now that you’ve heard all the theory, it’s time to start building the RESTful, event-driven version of the social media application. To keep the examples concise and focused on essential patterns, you will just be building the Account Management bounded context and some of the Discovery bounded context. From these examples, you will learn enough to begin using the concepts on your own projects.

我们将采用由外而内的方式构建 RESTful 社交媒体系统；首先，您将向“帐户管理”限界上下文添加超媒体入口点。然后，您将创建帐户 API。之后，您将创建用于发布“开始关注”事件的 Atom 源。最后，您将创建位于“发现”限界上下文中的“开始关注”源的消费者。

An outside-in approach will be taken to build the RESTful social media system; you will start by adding the hypermedia entry point to the Account Management bounded context. You’ll then create the Accounts API. After that you’ll create the Atom feed that publishes Began Following events. Finally, you’ll create the consumer of the Began Following feed that resides in the Discovery bounded context.

在接下来的示例中，为了方便起见，所有代码都将位于同一个 Visual Studio 解决方案中。但是，当您构建通过 HTTP 集成的 RESTful 系统时，这并非必要。事实上，您可能正在使用不同的技术，甚至无法共享解决方案。您可以自行决定哪种方案最佳；为系统的每个部分设置完全独立的代码存储库可以降低耦合度，但将代码紧密地放在一起可能有助于共享全局。

During the upcoming examples, all code will live in the same Visual Studio solution for convenience. But when you’re building RESTful systems that integrate over HTTP, this is not necessary. In fact, you may be using different technologies where it is not even possible to share a solution. It’s up to you to decide what you think is best; having completely separate code repositories for each part of the system encourages looser coupling, but keeping code close together may help to share the bigger picture.

要开始构建新的 RESTful 社交媒体系统，您可以先创建一个名为PPPDDD.REST.SocialMedia的新空白 Visual Studio 解决方案。

To begin building the new RESTful social media system, you can start by creating a new blank Visual Studio solution called PPPDDD.REST.SocialMedia.

超媒体驱动的 API

超媒体是 REST 的核心。因此，您现在将了解如何使用 ASP.NET Web API 在 .NET 中构建超媒体 API。虽然实现细节因框架而异，但这些概念与框架无关，并且适用于您用于构建超媒体 API 的任何工具。

Hypermedia is at the heart of REST. Accordingly, you will now see how to build hypermedia APIs in .NET with ASP.NET Web API. Although the implementation details will vary from framework to framework, the concepts are framework agnostic and will apply to any tools you may decide to build hypermedia APIs with.

正如你所见，超媒体的主要优势在于它解耦了客户端和服务器，允许它们独立发展。但客户端必须预先了解 API 的一些信息。这就是客户端应该将自身与入口点资源进行耦合的作用。

As you’ve seen, the key benefit of hypermedia is that it decouples clients and servers, allowing independent evolution. But clients must know something up front about the API. This is the role of the entry point resource that clients should couple themselves to.

入口点资源

当客户端想要与 REST API 交互时，他们首先会请求入口点资源。此后，他们通常只需跟随返回的超媒体中的链接即可。选择入口点的位置需要考虑许多因素。例如，图 13.10中的设计选择每个有界上下文只有一个入口点。但是你可以为整个系统设置一个入口点，或者更细粒度地为每个顶级资源设置一个入口点。最终，你必须根据每个项目的具体情况决定希望通过入口点资源公开多少系统内容。

When clients want to interact with a REST API, they start by requesting the entry point resource. From then on, they mostly just follow links in the hypermedia that is returned. Choosing where to locate your entry point(s) has a number of considerations that you should take into account. For instance, the design in Figure 13.10 chooses to have a single entry point per-bounded context. But you could have a single entry point for the entire system or go more fine-grained and have an entry point per top-level resource. Ultimately, you have to decide on a per-project basis how much of the system you want to expose via entry point resources.

设计入口点涉及确定 API 使用者应使用的初始资源和转换。帐户管理限界上下文的入口点将是顶级资源列表。在本例中，这只是帐户资源。从帐户资源开始，超媒体将链接到各个帐户，并从各个帐户链接到这些帐户的详细信息，这些详细信息以子资源的形式公开，例如其关注者。这只是重复您在本章前面的序列图中看到的内容。

Designing an entry point involves identifying the initial resources and transitions that should be available to consumers of the API. The Account Management bounded context’s entry point will be the list of top-level resources. In this example, that is just the Accounts resource. From the Accounts resource, hypermedia will link to individual accounts, and from individual accounts to details of those accounts, exposed as child resources, such as its followers. This is just repeating what you saw in the sequence diagram earlier in the chapter.

正如您开始看到的，链接是超媒体的基石。但是，为了让 API 客户端能够跟踪链接，他们需要能够决定哪个链接提供了他们想要的过渡。这就是链接关系的作用，它表明了链接所代表的内容（或者更具体地说，它与当前资源的关系）。例如，对于包含多个页面的资源，要符合超媒体规范，它需要一个带有“Next”关系的链接，客户端可以通过该链接跳转到下一页。在接下来的示例中，您将看到许多链接和关系。

As you’re starting to see, links are the building blocks of hypermedia. But for API clients to follow links, they need to be able to decide which link provides the transition they are looking for. This is the role of link relations, which indicate what the link represents (or, more specifically, its relationship to the current resource). For example, for a resource that has many pages, to be hypermedia-compliant, it would need a link with the relation Next, which clients can follow to the next page. You’ll see a number of links and relations in the upcoming examples.

要构建生成帐户管理入口点的 API，您需要首先向解决方案中添加一个名为AccountManagement.EntryPoint的新 ASP.NET 应用程序。这遵循基于格式{bounded context}.{Resource}命名 API 项目的约定。将项目添加到解决方案时，请务必选择空模板，并确保选中“Web API”复选框。

To build the API that produces the Account Management entry point, you need to start by adding a new ASP.NET application to the solution called AccountManagement.EntryPoint. This follows the convention of naming API projects based on the format {bounded context}.{Resource}. When adding the project to your solution, be sure to select the empty template, and be sure to check the Web API check box.

在添加生成入口点资源的端点之前，仍需要做出一个决定。您需要选择一种支持超媒体的媒体类型。

One decision still needs to be made before you can add the endpoint that produce the entry point resource. You need to choose a media type that supports hypermedia.

哈尔

传统上，XHTML 一直被用作 REST API 的超媒体格式。不幸的是，由于其冗长，它并不受欢迎（尤其是在试图摆脱 SOAP 的情况下）。幸运的是，不过，现在有一个相对较新的标准正在逐渐普及。这个新标准就是 HAL，本章前面已经简要介绍过，它主要有两种类型：XML 和 JSON。本质上，这两种众所周知的格式都通过特定的链接表示约定进行了扩展。这既提供了 XHTML 的超媒体优势，又避免了其冗长，如下例所示。

Traditionally, XHTML has been used as the hypermedia format for REST APIs. Unfortunately, it’s undesirable due to its verbosity (especially if you’re trying to escape from SOAP). Fortunately, though, a relatively new standard is available and gathering traction. This new standard is HAL, which was briefly introduced earlier in the chapter, and it comes in two main flavors: XML and JSON. Essentially, both of those well-known formats have been extended with specific conventions for representing links. This provides the hypermedia benefits of XHTML without the verbosity as the following example demonstrates.

{
  "_links": {
    "self": {
      "href":"http://localhost:4100/accountmanagement"
    },
    "accounts": {
      "href":"http://localhost:4101/accounts"
    },
 }
}

{
  "_links": {
    "self": {
      "href":"http://localhost:4100/accountmanagement"
    },
    "accounts": {
      "href":"http://localhost:4101/accounts"
    },
 }
}

上述代码片段中显示的入口点资源演示了在 HAL (JSON) 中表示链接的约定。所有链接都必须在资源根目录下名为_links的元素内定义。每个链接都以其关系（示例中为self和accounts）开头。每个链接还包含一个 href，即其指向的资源的 URI。只有指向当前资源的self链接是必需的；所有其他链接都是可选的。

The entry point resource shown in the preceding snippet demonstrates the conventions for representing links in HAL (JSON). All links must be defined within an element at the root of the resource called _links. Each link begins with its relation (self and accounts in the example). Each link also contains an href, which is the URI of the resource it points to. Only the self link, which points to the current resource, is mandatory; all other links are optional.

要构建入口点资源 API，首先需要将项目配置为在端口 4100 上启动。（可以在项目属性的【Web】选项卡上进行设置。）然后，需要通过在 Web API 的 WebAPIConfig 中添加路由来配置入口点的 URI ，如清单 13-8 所示。WebApiConfig文件将位于项目根目录中的App_Start文件夹中。

To build the entry point resource API, you first need to configure the project to start on port 4100. (You can set this in the project’s properties on the Web tab.) You then need to configure a URI for the entry point by adding a route inside Web API’s WebAPIConfig, as shown in Listing 13-8. Your WebApiConfig file will be located in the App_Start folder that sits in the root of the project.

如果您不熟悉 Web API 的路由语法，在清单 13-8 中，入口点路由的定义确保每当路径 /accountmanagement 收到请求时，都会调用名为EntryPointController的类上的Get()方法。在实现该控制器之前，您需要安装一个 Nuget 包，该包在 Web API 中添加了对 HAL 的支持。正如您将看到的，这是一个非常实用的库，它省去了创建 HAL API 的所有精力。要将WebApi.Hal安装到AccountManagement.EntryPoint.Api项目中，您需要在 Nuget 包管理器控制台中运行以下命令：

If you’re not familiar with Web API’s routing syntax, in Listing 13-8, the definition of the Entry Point route ensures that whenever a request comes in for the path /accountmanagement, the Get() method on a class called EntryPointController is invoked. Before you can implement that controller, you need to install a Nuget package that adds support for HAL in Web API. As you will see, this is an incredibly usable library that takes all the effort out of creating HAL APIs. To install WebApi.Hal into the AccountManagement.EntryPoint.Api project, you need to run the following command in the Nuget Package Manager Console:

Install-Package WebApi.Hal -Project AccountManagement.EntryPoint.Api

Install-Package WebApi.Hal -Project AccountManagement.EntryPoint.Api

安装WebApi.Hal后，您需要通过更新Global.asax.cs文件来告诉 Web API 将 HAL (JSON) 设置为默认媒体类型，如清单 13-9 所示。这也会将 HAL (XML) 设置为第二首选项。这两个格式化程序JsonHalMediaTypeFormatter和XmlHalMediaTypeFormatter都属于您刚刚安装的WebAPI.Hal包。

Once WebApi.Hal is installed, you need to tell Web API to make HAL (JSON) the default media type by updating your Global.asax.cs, as per Listing 13-9. This also sets HAL (XML) as the second preference. The two formatters, JsonHalMediaTypeFormatter and XmlHalMediaTypeFormatter, belong to the WebAPI.Hal package you just installed.

所有依赖项均已安装完毕，配置也已完成，接下来可以通过实现EntryPointController来完成 Entry Point API 。您可以先通过以下方式实现：在项目根目录下的Controllers文件夹中添加一个名为EntryPointController的类。添加该类后，可以用清单 13-10 中的代码替换文件的内容。

All dependencies are installed and configuration is now complete, paving the way for you to complete the Entry Point API by implementing the EntryPointController. You can achieve this by first adding a class called EntryPointController to the Controllers folder that sits at the root of the project. Once you’ve added the class, you can then replace the contents of the file with the code in Listing 13-10.

清单 13-10 中的代码执行时，将默认以 HAL-JSON 格式返回入口点资源。这是因为EntryPointRepresentation继承自Representation基类——WebApi.Hal库提供的一个类。当从控制器方法返回继承自Representation 的类时， JsonHalMediaTypeFormatter会将其转换为 HAL-JSON。

The code in Listing 13-10, when executed, will return the entry point resource as HAL-JSON (by default). This is because EntryPointRepresentation inherits from the Representation base class—a class that the WebApi.Hal library provides. When a class inheriting from Representation is returned from a controller method, the JsonHalMediaTypeFormatter will convert it to HAL-JSON.

在Get()内部，代码以声明方式映射到响应格式。您可以看到此代码生成了两个链接：Href和Links（一个只有一个链接的集合）。这两个链接将出现在响应中。您可以通过测试目前为止的内容来了解​​所有这些操作的实际效果。

Inside Get(), the code declaratively maps onto the response format. You can see two links are being generated in this code: Href and Links (a collection with just one link). These are the two links that will appear in the response. You can see all this in action by testing out what you have so far.

使用 HAL 浏览器测试 HAL API

基于通用标准构建超媒体 API 的一大优势在于，可以轻松创建通用客户端，用于探索使用这些标准构建的 API。HAL 的其中一种工具就是 Hal 浏览器，它是一个小型 Web 应用，允许您使用 HAL API 并与之交互。现在，您将了解如何使用 HAL 浏览器来测试您刚刚构建的入口点 API。

A huge benefit of building hypermedia APIs on top of common standards is that it is easy to create generic clients that can explore APIs built using those standards. One such tool for HAL is the Hal browser, a small web application that allows you to consume and interact with HAL APIs. You’ll now see how to use the HAL browser to test the Entry Point API you have just built.

要安装 HAL 浏览器，您需要下载它（https://github.com/mikekelly/hal-browser/archive/master.zip）并解压。最后，您需要将解压后的文件夹内容复制到Windows 资源管理器中AccountManagement.EntryPoint.Api项目的根目录下。如果您在 Windows 资源管理器中打开AccountManagement.EntryPoint.Api项目的根目录，应该会看到一个名为browser.html的文件。如果您没有看到该文件，则说明该文件的位置不正确。

To install the HAL browser, you have to download it (https://github.com/mikekelly/hal-browser/archive/master.zip) and then unzip it. Finally, you need to copy the contents of the unzipped folder into the root of your AccountManagement.EntryPoint.Api project’s folder in Windows Explorer. If you open Windows Explorer at the root of the AccountManagement.EntryPoint.Api project, there should be a file called browser.html. If you don’t see it, the file is in the wrong location.

如果您确认文件已复制到正确的位置，则可以按 F5 运行项目。在 Visual Studio 启动的浏览器中，您可以通过导航至http://localhost:4100/browser.html来访问 HAL 浏览器。（这假设您已将此项目配置为始终使用端口 4100，如前所述。）导航至browser.html后，如果一切正常，您将看到 HAL 浏览器，如图13.13所示。

If you are happy that the files are copied into the correct location, you can press F5 to run your project. In the browser that Visual Studio starts up for you, you can access the HAL browser by navigating to http://localhost:4100/browser.html. (This assumes that you configured this project to always use port 4100, as explained previously.) After navigating to browser.html, if everything is working correctly, you will see the HAL browser, as per Figure 13.13.

当您访问 HAL 浏览器时，您会注意到它没有显示您的入口点资源。这是因为 HAL 浏览器在默认路径 (/) 下查找 API 入口点。要解决这个问题，只需在 HAL 浏览器的导航栏（Explorer 标签下方）输入/accountmanagement，然后点击“GO”。然后，您应该会看到原始入口点资源（在右侧）和交互式工具（在左侧），如图13.14所示。

When you do access the HAL browser, you’ll notice it doesn’t show your entry point resource. This is because the HAL browser looks for API entry points at the default path (/). To remedy this, simply enter /accountmanagement into the HAL browser’s navigation bar (below the Explorer label) and click GO. You should then see the raw entry point resource (on the right side) and the interactive tools (on the left side), as shown in Figure 13.14.

目前，HAL 浏览器几乎没有提供什么帮助，因为入口点资源中的链接指向了不存在的资源。所以你的下一个任务是：实现 Accounts API。如图13.14中的入口点资源所示，Accounts 资源需要能够通过http://localhost:4101/accountmanagement/accounts访问。

At the moment, the HAL browser provides little benefit because the links in the entry point resource point to nonexistent resources. So this is your next task: to implement the Accounts API. As the entry point resource in Figure 13.14 shows, the Accounts resource needs to be accessible at http://localhost:4101/accountmanagement/accounts.

URI 模板

在构建 Accounts API 的过程中，你将了解如何解决人们对超媒体的一个常见问题：导航效率低下。假设一个 API 暴露了大量数据，例如数千甚至数百万个账户。客户端可能需要浏览数百个链接才能找到所需的资源，成功跟踪到下一页的链接。显然，这对于客户端和服务器来说效率非常低下，尤其是对于拥有大量并发客户端的公共 API 来说。这个问题可以通过使用 URI 模板来解决。

In building the Accounts API, you will see how to handle a common concern people have for hypermedia: inefficient navigation. Consider an API that exposes lots of data, such as thousands or millions of accounts. Clients may have to navigate hundreds of links to find the resource they want by successfully following links to the next page. Obviously, this can be massively inefficient for the client and the server—especially for public APIs with many concurrent clients. This problem is solved by using URI templates.

以下示例展示了 Accounts 资源的 HAL (JSON) 格式，您稍后将为其创建 API。查找 URI 模板；它是templated属性设置为true 的链接：

The following sample shows the Accounts resource, as HAL (JSON), that you are going to create an API for shortly. Look for the URI template; it’s the link whose templated attribute is set to true:

{
  "_links": {
    "self": {
      "href":"http://localhost:4101/accountmanagement/accounts"
    },
    "alternative": {
      "href":"http://localhost:4101/accountmanagement/accounts?page=1"
    },
    "account": [
      {
        "href":"http://localhost:4101/accountmanagement/accounts/{accountId}",
        "templated": true
      },
      {
        "href":"http://localhost:4101/accountmanagement/accounts/123"
      },
      ...
}

{
  "_links": {
    "self": {
      "href":"http://localhost:4101/accountmanagement/accounts"
    },
    "alternative": {
      "href":"http://localhost:4101/accountmanagement/accounts?page=1"
    },
    "account": [
      {
        "href":"http://localhost:4101/accountmanagement/accounts/{accountId}",
        "templated": true
      },
      {
        "href":"http://localhost:4101/accountmanagement/accounts/123"
      },
      ...
}

要表示 URI 模板，您不仅需要将templated属性设置为true，还必须在 URI 中添加占位符部分。在刚刚显示的 Accounts 资源响应中，您可以看到占位符是{accountId}。然后，API 的客户端可以将占位符替换为他们要查找的帐户的 ID。这样，您就可以将数百个潜在请求精简为一个。使用WebApi.Hal创建 URI 模板几乎不费吹灰之力，正如您在创建 Accounts API 时所看到的那样。

To represent URI templates, not only do you need to set the templated attribute to true, but you must also add placeholder sections in the URI. In the Accounts resource response just shown, you can see the placeholder is {accountId}. Clients of the API can then replace the placeholder with the ID of the account they are looking for. In doing so, you cut down hundreds of potential requests into just a single one. Creating URI templates with WebApi.Hal requires little effort, as you will now see while creating the Accounts API.

您可以通过添加一个名为AccountManagement.Accounts.Api的新项目来创建 Accounts API 。您需要将其设置为启动项目，并确保它在端口 4101 上运行。创建完成后，您可以通过在 Nuget 包管理器控制台中运行以下命令来添加对WebApi.Hal的引用：

You can create the Accounts API by adding a new project called AccountManagement.Accounts.Api. You need to set this as a start-up project and ensure that it runs on port 4101. Once it’s created, you can then add a reference to WebApi.Hal by running the following command in the Nuget Package Manager console:

Install-Package WebApi.Hal -Project AccountManagement.Accounts.Api

Install-Package WebApi.Hal -Project AccountManagement.Accounts.Api

最后的配置步骤是将 HAL 设置为默认内容类型，如前面的清单 13-9 所示。

The final configuration step is to set HAL as the default content type, as shown previously in Listing 13-9.

Accounts API 将公开两个 URI。首先，客户端将单击 /accountmanagement/accounts 上的 Accounts 资源，该资源代表整个帐户列表。然后，客户端将使用 Accounts 资源中包含的 URI 模板（accountmanagement/accounts/{accountId}）导航到各个帐户。要在项目中声明这些路由，AccountManagement.Accounts.Api项目中的WebApiConfig应类似于清单 13-11。

Two URIs will be exposed by the Accounts API. Initially, clients will click the Accounts resource at /accountmanagement/accounts, which represents the entire list of accounts. From there, clients will then navigate to individual accounts using the URI template contained within the Accounts resource—accountmanagement/accounts/{accountId}. To declare these routes in your project, the WebApiConfig in your AccountManagement.Accounts.Api project should resemble Listing 13-11.

如清单 13-11 中的路由声明所示，需要将一个名为AccountsController的类添加到Controllers文件夹（仍在AccountManagement.Accounts.Api内）。它需要两个方法—— Index()和Accounts() ——由路由定义决定。从Index()开始，AccountsController最初应该包含清单 13-12 所示的代码。

As the route declarations in Listing 13-11 show, a class called AccountsController needs to be added to the Controllers folder (still inside AccountManagement.Accounts.Api). It needs two methods—Index() and Accounts()—as dictated by the route definitions. Starting with just Index(), the AccountsController should initially contain the code shown in Listing 13-12.

清单 13-12 中的大部分代码与清单 13-10 中的代码类似，但值得注意的是新增的链接。备用链接关系表示具有不同 URI 但指向同一资源（self）的链接。这样做的好处之一是，客户端可以通过将两个 URI 视为同一资源来更高效地缓存。备用链接下方是模板化的帐户链接，由于href包含占位符，WebApi.Hal会自动将其标记为模板化。

Most of the code in Listing 13-12 will be familiar from Listing 13-10, but it is worthwhile noting the additional links. The alternative link relation represents links that have a different URI but point to the same resource (self). One benefit of this is that clients can cache more efficiently by treating both URIs as the same resource. Below the alternative link is the templated account link, which WebApi.Hal automatically marks as templated because the href contains a placeholder.

在 HAL 浏览器中测试新 API 之前，您需要启用跨域资源共享 (CORS)。这是因为 Accounts 资源由不同的虚拟主机（端口 4101 而不是 4100）提供。启用 CORS 的详细说明请参阅 ASP.NET 网站 ( http://www.asp.net/web-api/overview/security/enabling-cross-origin-requests-in-web-api )。基本上，您需要执行以下操作：

Before you can test the new API in the HAL browser, you need to enable Cross-Origin Resource Sharing (CORS). This is because the Accounts resource is provided by a different vhost (port 4101 as opposed to 4100). The instructions for enabling CORS are detailed on the ASP.NET website (http://www.asp.net/web-api/overview/security/enabling-cross-origin-requests-in-web-api). Basically, you need to do the following:

1. 通过在 Nuget 包管理器控制台中运行以下命令将 CORS 包添加到项目中：

   
   Install-Package Microsoft.AspNet.WebApi.Cors -Project AccountManagement.Accounts.Api

2. Add the CORS package to the project by running the following command inside the Nuget Package Manager Console:

   
   Install-Package Microsoft.AspNet.WebApi.Cors -Project AccountManagement.Accounts.Api

3. 在WebApiConfig中配置 CORS ，如清单 13-13 所示。
4. Configure CORS in WebApiConfig, as per Listing 13-13.

如果您像以前一样运行 HAL 浏览器，从入口点开始并按照指向 Accounts 资源的链接，您将看到 URI 模板链接，如图13.15所示。

If you run the HAL browser as before, starting at the entry point and following the link to the Accounts resource, you will see the URI template link, as per Figure 13.15.

URI 模板并非全有或全无；您可以将它们与普通链接组合使用，即使对于同一资源也是如此。图 13.15包含两个非模板化的“帐户”链接来说明这一点。它们直接指向 Account 资源。但是，要使这些链接正常工作，您需要向AccountsController添加一个Account()方法。（这由清单 13-11 所示的路由条目决定。）

URI templates are not all or nothing; you can combine them with normal links, even for the same resource. Figure 13.15 contains two nontemplated “account” links that illustrate this. They point directly to Account resources. For those links to work, though, you need to add an Account() method to the AccountsController. (This is determined by the route entry shown in Listing 13-11.)

Account()的初始实现（仅返回预设数据）如清单 13-14 所示。您可以将其添加到AccountsController 的Index()下方。您还需要添加清单 13-15 中的AccountRepresentation和Account类。（您可以将它们全部放在AccountsController.cs文件中。）

An initial implementation of Account(), which returns just canned data, is shown in Listing 13-14. You can add this to your AccountsController below Index(). You also need to add the AccountRepresentation and Account classes from Listing 13-15. (You can put them all inside the AccountsController.cs file.)

资源的字段（而不是链接）在 HTTP 响应中以标准 JSON 格式表示。在清单 13-15 中，您可以看到AccountRepresentation具有属性AcountId和名称。因此，如果您使用 Hal 浏览器导航到 Account 资源，您将看到这些属性以纯 JSON 格式表示。图 13.16也展示了这一点。

A resource’s fields (as opposed to its links) are represented as standard JSON in an HTTP response. In Listing 13-15, you can see that an AccountRepresentation has the properties AcountId and Name. Therefore, if you navigate to an Account resource using the Hal browser, you will see these properties represented as plain JSON. Figure 13.16 also shows this.

图 13.16还显示了一些值得注意的链接。具体来说，指向此帐户子资源的三个链接分别是followers、following和blurbs。您将在下一节中构建 followers 端点，但其他两个链接只是为了让您了解具有许多子资源的资源应该是什么样子。构建followers端点之后，您将开始使用事件存储构建系统的事件驱动部分。

Figure 13.16 also shows some noteworthy links. In particular, the three links that point to child resources of this account are followers, following, and blurbs. You’re going to build the followers endpoint in the next section, but the other two links are just to give you an idea of how a resource with many child resources could look. Building the followers endpoint is where you will start to build the event-driven parts of the system using the Event Store.

使用事件存储持久化事件

大部分基础架构都已准备就绪，可供您学习如何使用 REST 构建事件驱动系统。学习的第一部分涉及存储事件。您可以通过多种方式实现这一点，例如将事件写入文本文件日志或使用 SQL 数据库中的表。但在本例中，您将看到一个专门构建的工具——事件存储 (Event Store)，它是由著名的 DDD 从业者 Greg Young 及其团队 ( www.geteventstore.com ) 开发的。

Most of the infrastructure is in place for you to learn about building event-driven systems with REST. The first part of your learning involves storing events. There are many ways you can achieve this, such as writing events to a text file log or using a table in a SQL database. But in this example, you will see a purpose-built tool—the Event Store—that is the work of popular DDD practitioner Greg Young and his team (www.geteventstore.com).

要了解如何存储事件，您需要在 Accounts API 中构建一个新的端点，该端点返回帐户的关注者。此端点支持通过发布到集合中来添加新的关注者。此流程之前已在图 13.11中说明。像往常一样，创建用于公开资源的新端点的第一步是从路由定义开始。清单 13-16 显示了如何更新WebApiConfig以添加 Followers 端点的路由定义。

To learn about storing events, you need to build a new endpoint in your Accounts API that returns the followers of an account. This endpoint supports the ability to add new followers to the collection by posting to it. This flow was previously illustrated in Figure 13.11. As usual, the first step to creating a new endpoint for exposing resources is to start with the route definition. Listing 13-16 shows how your WebApiConfig should be updated to add the route definition for the Followers endpoint.

清单 13-16 显示，Followers 资源将由名为FollowersController 的控制器上的Index()方法提供。您可以通过在项目的Controllers文件夹中添加一个名为FollowersController的类来创建该控制器，类似于清单 13-17。

Listing 13-16 shows that the Followers resource will be served up by a method called Index() on a controller called FollowersController. You can create that controller by adding a class called FollowersController, in your project’s Controllers folder, that resembles Listing 13-17.

清单 13-17 中Index()的实现仅返回一个预设响应，并以传入的 Account ID 作为参数。这并不是本例的重点——响应发布到端点的数据并持久化事件才是重要且令人兴奋的部分。清单 13-18 中可以看到触发该过程，其中展示了需要添加到FollowersController中GetFollowers()正下方的代码。此外，还需要添加清单 13-19 中所示的BeganFollowing类。

The implementation of Index() in Listing 13-17 merely returns a canned response, parameterised with the passed-in Account ID. This is not the important part of this example—persisting an event in response to data being posted to the endpoint is the important and exciting part. You can see that process being triggered in Listing 13-18, which shows the code that needs to be added to your FollowersController directly below GetFollowers(). Also, you need to add the BeganFollowing class that is shown in Listing 13-19.

如清单 13-18 所示， IndexPOST()响应/accountmanagement/accounts/{accountId}/followers的 post 请求。您可以看到这一点，因为该方法具有HttpPost属性。由于同一文件中还有另一个名为Index () 的方法，因此ActionName属性指示即使此方法名为IndexPOST()，它仍应响应Account Followers路由的请求。

IndexPOST(), shown in Listing 13-18, responds to post requests for /accountmanagement/accounts/{accountId}/followers. You can see this because the method is attributed with the HttpPost attribute. Because of another method called Index () in the same file, the ActionName attribute indicates that it should still respond to requests for the Account Followers route even though this method is named IndexPOST().

关键的事件持久化机制并未包含在清单 13-18 中。不过，您可以看到对EventPersister.PersistEvent()的调用。这是处理事件持久化的类。您可以在清单 13-20 中看到它的内容，其中展示了将事件持久化到事件存储的最低限度的功能。您需要将此类添加到项目中。为了方便起见，您可以将其放在AccountsController.cs文件的底部（但在AccountsController类之外）。不过，在添加EventPersister之前，您需要使用以下命令安装事件存储 C# 客户端：

The crucial event-persistence mechanics are not included in Listing 13-18. You can, though, see a call to EventPersister.PersistEvent(). This is the class that handles event persistence. You can see the contents of it in Listing 13-20, which shows the bare-minimum functionality for persisting events to the Event Store. You need to add this class to your project. For convenience, you can put it at the bottom of the AccountsController.cs file (but outside of the AccountsController class). Before adding the EventPersister, though, you need to install the Event Store C# client with the following command:

Install-Package EventStore.Client -Project AccountManagement.Accounts.Api

Install-Package EventStore.Client -Project AccountManagement.Accounts.Api

为了编译EventPersister ，您需要包含以下使用语句：

For the EventPersister to compile, you need to include the following using statements:

using EventStore.ClientAPI;
using Newtonsoft.Json;
using System.Net;
using System.Text;

using EventStore.ClientAPI;
using Newtonsoft.Json;
using System.Net;
using System.Text;

在清单 13-20 所示的代码中，有两个关键细节需要关注：事件被转换为 JSON（然后转换为二进制），并被附加到一个流——在本例中是BeganFollowing流。一旦事件存储启动并运行，您将更好地理解所有这些是如何工作的。

Of the code shown in Listing 13-20, there are two key details to focus on: the event is converted to JSON (and then binary), and it is appended to a stream—the BeganFollowing stream in this case. You will get a better understanding of how all of this works once the Event Store is up and running.

安装并启动事件存储

本示例使用 Event Store 2.0.1 版本（http://download.geteventstore.com/binaries/EventStore-OSS-Win-v2.0.1.zip）。下载完成后，只需将压缩包解压到一个目录中，然后以管理员身份在该目录中运行以下 PowerShell 命令即可：

This example uses version 2.0.1 of the Event Store (http://download.geteventstore.com/binaries/EventStore-OSS-Win-v2.0.1.zip). Once you’ve downloaded it, you just need to extract the archive into a directory and then run the following PowerShell command from that directory (as Administrator):

./EventStore.SingleNode.exe --db .\ESData

./EventStore.SingleNode.exe --db .\ESData

要确认事件存储已成功启动，您应该能够通过http://localhost:2113访问管理应用程序。成功确认后，您将看到如图 13.17所示的欢迎页面。如果您没有看到欢迎屏幕，请仔细检查您是否以管理员身份运行了 PowerShell。此外，请查看控制台上是否打印了任何错误信息。PowerShell 控制台。如果您看到欢迎页面，则表示事件存储正在运行，并且正在耐心等待保存您的所有事件。

To confirm that the Event Store has started up successfully, you should be able to access the management application by going to http://localhost:2113. As confirmation of success, you are presented with the welcome page shown in Figure 13.17. If you don’t see the welcome screen, double-check that you ran PowerShell as Administrator. Also, look to see if there were any errors printed on the PowerShell console. If you do see the welcome page, that means the Event Store is running and is now patiently waiting to persist all your events.

使用事件存储管理 UI 查看持久事件

您刚刚浏览了事件存储管理界面，现在您将通过查看通过 Accounts API 创建的事件来探索它的一些关键功能。要将事件导入系统，您需要发布新关注者的详细信息。为了演示，您可以在启动系统后，通过 HAL 浏览器转到入口点（HAL 浏览器中的 /accountmanagement）来完成所有操作。然后，您需要点击链接访问 Accounts 资源。从 Accounts 资源，您需要点击链接访问其中一个虚拟帐户，然后从那里点击链接访问其关注者资源。

You just saw a glimpse of the Event Store admin UI, and now you will explore some of its key features as you view events that are being created via the Accounts API. To get events into the system, you need to post details of new followers. For demonstration purposes, you can do all this through the HAL browser by going to the entry point (/accountmanagement in the Hal browser) after you have started the system. You then need to follow the link to the Accounts resource. From the Accounts resource, you need to follow the link to one of the dummy accounts, and from there follow the link to its followers resource.

如果要向关注者资源发布帖子，则需要点击代表自身链接的行的“NON-GET”列中的橙色按钮。此按钮如图 13.18所示。点击此按钮将打开一个对话框，允许您构建将发布到端点的 JSON 负载。图 13.19显示了正确格式的 JSON 数据正在被输入到此对话框中，其中包含新关注者的详细信息。输入 JSON 数据后，单击“确定”按钮，您的 JSON 数据便会发布。

If you want to post to the followers resource, you need to click the orange button in the NON-GET column for the row that represents the self link. This button is shown in Figure 13.18. Clicking this button opens a dialog enabling you to construct a JSON payload that will be posted to the endpoint. Figure 13.19 shows correctly formatted JSON being entered into this dialog containing the details of a new follower. Once you’ve entered some JSON, click the OK button, and your JSON is posted.

如果您在发布 JSON 后收到了200响应，现在就可以使用事件存储的管理界面查看该事件了。导航到http://localhost:2113/并选择“Streams”菜单项后，您应该会看到一个名为BeganFollowing的流，它是在您从 HAL 浏览器发布消息时创建的。您可以点击其名称来查看该流中的事件。然后，您可以检查各个事件，如图13.20所示。

Providing you got a 200 response back from posting the JSON, you can now view the event using the Event Store’s admin UI. After navigating to http://localhost:2113/ and choosing the Streams menu item, you should see a stream called BeganFollowing that was created when you posted from the HAL browser. You can click on its name to view events in that stream. From there, you can inspect individual events, as shown in Figure 13.20.

将事件发布到 Atom Feed

Atom 是许多 RESTful 系统中事件公开的明智之选，因为它是一种极其常见的格式，正如本章前面所讨论的。在本例中，您将了解如何使用 .NET 框架内置的工具来创建和发布 Atom 源。

Atom is a discerning choice for exposing events in many RESTful systems because it is an extremely common format, as discussed earlier in the chapter. In this example, you will see how to use the tools baked into the .NET framework for creating and publishing an Atom feed.

将事件发布为 Atom 源的应用程序类似于消息传递系统中的消息发布组件。因此，对于事件驱动的 REST 系统，您可以使用类似的命名约定来传达领域概念，例如{BoundedContext}.{BusinessComponent}.{Component}。

Applications that publish events as an Atom feed are akin to message-publishing components in a messaging system. Accordingly, for an event-driven REST system, you can use a similar naming convention that communicates domain concepts, such as {BoundedContext}.{BusinessComponent}.{Component}.

要创建发布“Began Following”域事件的组件，可以先向项目中添加一个名为AccountManagement.RegularAccounts.BeganFollowing的新 ASP.NET Web 应用程序。您需要将此应用程序配置为在端口 4102 上运行，并使其成为启动项目。

To create the component that publishes the Began Following domain event, you can start by adding a new ASP.NET Web Application to the project called AccountManagement.RegularAccounts.BeganFollowing. You need to configure this application to run on port 4102 and make it a start-up project.

在 .NET 中创建基本 Atom Feed

要使用 .NET Framework 的官方库创建 Atom 提要，首先需要在新的 AccountManagement.RegularAccounts.BeganFollowing 项目中添加对 System.ServiceModel 的引用。设置路由定义后，如清单 13-21 所示，然后可以使用 System.ServiceModel 中的类，使用从事件存储中检索到的事件创建 Atom 提要，如清单 13-22 所示。清单 13-22 中的代码需要作为新的控制器添加到Controllers文件夹中。

To create an Atom feed using official libraries that are part of the .NET work framework, you first need to add a reference to System.ServiceModel in the new AccountManagement.RegularAccounts.BeganFollowing project. After setting up a route definition, shown in Listing 13-21, you can then use classes from System.ServiceModel to create an Atom feed using events retrieved from the Event Store, as shown in Listing 13-22. The code in Listing 13-22 needs to be added as a new controller in the Controllers folder.

如清单 13-22 所示，使用SyndicationFeed类创建了一个 Atom feed。然后，通过XmlWriter将创建的 feed 设置为 HTTP 请求的响应。在响应对象上，将application/atom+xml设置为内容类型。这将直接作为 HTTP Content-Type响应头的值传递。还可以看到，从事件存储（EventRetriever.RecentEvents()）被转换为FeedItems。但是清单 13-22 中没有展示如何从事件存储中检索事件。这将在下文展示。

As you can see in Listing 13-22, an Atom feed is created using the SyndicationFeed class. The created feed is then set as the response of the HTTP request via an XmlWriter. On the response object, application/atom+xml is set as the content type. This will be passed directly as the value for the HTTP Content-Type response header. You can also see that individual events, retrieved from the Event Store (EventRetriever.RecentEvents()), are converted into FeedItems. But what you can’t see in Listing 13-22 is how to retrieve the events from the Event Store. That is shown next.

从事件存储中检索事件

在清单 13-22 中，通过使用自定义实用程序类EventRetriever从事件存储中检索事件来生成各个 feed 项。EventRetriever的内容如清单 13-23 所示，需要将其添加到项目中。为了方便起见，如果您不想创建另一个文件，可以将其放在包含BeganFollowingController的文件底部。

In Listing 13-22, individual feed items are generated by retrieving events from the Event Store using a custom utility class: EventRetriever. The contents of EventRetriever are shown in Listing 13-23 and need to be added to your project. To make life easy, you can pop it in the bottom of the file containing the BeganFollowingController if you don’t want to create another file.

EventRetriever是一个包装 Event Store C# 客户端的实用程序类。它被硬编码用于检索过去 20 个事件，从最近的事件开始。这可以通过使用ReadStreamEventsForward来实现，该函数从最近的事件开始，然后向后执行。Event Store C# 客户端提供的许多功能本书并未涵盖，因此，如果您正在考虑使用 Event Store 和 C# 客户端，Event Store 网站包含大量实用信息。

EventRetriever is a utility class that wraps the Event Store C# client. It is hard-coded to retrieve the past 20 events, starting from the most recent. This is enabled by using ReadStreamEventsForward, which starts with the most recent events and works backward. There’s a lot of functionality provided by the Event Store C# client that isn’t covered in this book, so if you’re thinking about using the Event Store and the C# client, the Event Store website contains lots of useful information.

为了使EventRetriever能够编译，您还需要在此项目中添加对 Event Store C# 客户端的引用。以下命令将负责安装它：

For the EventRetriever to compile, you need to add a reference to the Event Store C# client in this project as well. The following command takes care of installing it for you:

Install-Package EventStore.Client -Project AccountManagement.RegularAccounts.BeganFollowing

Install-Package EventStore.Client -Project AccountManagement.RegularAccounts.BeganFollowing

要测试 Atom feed 是否按预期工作，首先需要更新入口点资源（在AccountManagement.EntryPoint.Api项目中），以提供指向 Atom feed 的链接（记住，客户端不应该与资源耦合，而应该与入口点耦合）。清单 13-24 显示了包含所需链接的更新后的入口点资源。将资源添加到您的项目，您可以通过直接在浏览器中查看来测试提要（如果您只是测试它，直接访问资源是可以的）：http://localhost:4102/accountmanagement/beganfollowing。

To test that your Atom feed is working as expected, you first need to update the entry point resource (in the AccountManagement.EntryPoint.Api project) to provide a link to the Atom feed (remember, clients should not be coupled to resources, only the entry point). Listing 13-24 shows the updated entry point resource containing the required link. Once the resource is added to your project, you can test the feed by viewing it directly in a browser (accessing a resource directly is okay if you’re just testing it): http://localhost:4102/accountmanagement/beganfollowing.

归档 Feed

在一个高度可扩展且可能拥有数百万用户的系统中，每秒可能会有数百或数千个事件。如果用一个 Atom feed 来存储所有这些事件，很快就会变得无法使用。这可能会导致大量的网络带宽浪费，以及其他与效率低下相关的问题。一个常见的解决方案是每个 feed 显示固定数量的事件，一旦达到容量上限，就将 feed 归档。重要的是，每个 feed 都包含指向上一个和下一个归档（如果存在）的超媒体链接。欲了解更多信息，请参阅互联网工程任务组 (IETF) 发布的题为“Feed 分页和归档”的征求意见稿 (RFC) ( https://tools.ietf.org/html/rfc5005 )。

In a highly scalable system with potentially millions of users, there may be hundreds or thousands of events every second. Having a single Atom feed for all these events would quickly become unusable. This could result in a massive waste of network bandwidth, as well as other inefficiency-related issues. A common solution is to display a fixed number of events per-feed, and once a capacity is reached to then archive the feed. Importantly, each feed contains hypermedia links to the previous and next archives (if they exist). For more information, the Internet Engineering Task Force (IETF) has a request for comments (RFC) titled “Feed Paging and Archiving” (https://tools.ietf.org/html/rfc5005).

创建事件订阅者/Atom Feed 消费者

使用公开领域事件的 Atom 源类似于在消息系统中订阅消息。然而，使用 Atom 源会反转接收推送消息的过程，改为轮询和拉取消息。对于开发人员来说，这需要更多的前期工作，但它确实具有显著的优势。

Consuming an Atom feed that exposes domain events is akin to subscribing to messages in a messaging system. However, consuming an Atom feed inverts the process of receiving pushed messages by polling and pulling them instead. It’s a little more work up-front for developers, but it definitely has compelling advantages.

在创建 Atom 源的消费者时，您可以再次利用 Atom 的流行优势，使用 .NET 框架中的官方库。在构建 Discovery 限界上下文的第一部分（用于轮询 Began Following Atom 源）时，您很快就会看到这一点。为此创建的项目不必是 Web 项目。相反，您可以创建一个名为Discovery.Recommendations.Followers的新 C# 类库（如图 13.10中的容器图所示）。与之前一样，要利用 .NET 的简易聚合 (RSS) 库，您需要添加对System.ServiceModel的引用。您还需要将此项目配置为启动项目。

When creating a consumer of an Atom feed, you can again take advantage of Atom’s popularity by using official libraries in the .NET framework. You’ll see this shortly as you build the first part of the Discovery bounded context that polls the Began Following Atom feed. The project you create for this does not need to be a web project. Instead, you can create a new C# Class Library called Discovery.Recommendations.Followers (as per the containers diagram in Figure 13.10). As before, to take advantage of .NET’s really simple syndication (RSS) libraries, you need to add a reference to System.ServiceModel. You also need to configure this project as a start-up project.

通过轮询订阅事件

在新的轮询组件中，您即将添加的逻辑由几个通用步骤组成。这些步骤与您构建的任何 Atom 信息流轮询应用程序中的步骤可能类似。

Inside the new polling component, the logic you are about to add consists of a few generic steps. These steps are likely to be similar in any Atom-feed polling application you build.

1. 从处理的最后一个事件 ID 开始获取一批事件（如果尚未处理任何事件，则从第一个项目开始）。
2. Fetch a batch of events starting from the last event ID that was processed (or the first item if no event has been processed yet).
3. 根据域策略处理批次中的每个项目。
4. Process each item in the batch according to domain policies.
5. 存储最后处理的事件的 ID。
6. Store the ID of the last event processed.

清单 13-25 展示了为 Discovery 有界上下文实现轮询消费者的第一部分。这仅包含高级逻辑。您可以将所有这些代码添加到项目根目录中名为BeganFollowingPollingFeedConsumer的单个类中。

The first part of implementing the polling consumer for the Discovery bounded context is shown in Listing 13-25. This contains only the high-level logic. You can add all this code to your project inside a single class called BeganFollowingPollingFeedConsumer in the root of the project.

清单 13-25 展示了 feed 消费者的第一部分。它演示了如何从 feed 中检索并处理一批事件。可以看到，通过调用Thread.Sleep() ，轮询被设置为每秒最多一次。

Listing 13-25 shows the first part of the feed consumer. It illustrates how a batch of events will be retrieved from the feed and processed. You can see polling is set to a maximum of once per second with the call to Thread.Sleep().

现在焦点转移到实际获取 feed 的底层细节。如清单 13-26 所示；它是一个 REST API 客户端的示例，它跟踪超媒体中的链接，从入口点到目标资源。您需要将此代码直接添加到清单 13-25 中添加的代码下方。您还需要通过运行以下命令将ServiceStack.Text添加到项目中：

Focus now shifts to the lower-level details of actually fetching the feed. This is shown in Listing 13-26; it’s an example of a REST API client following links in hypermedia from an entry point to a target resource. You need to add this code directly below the code you added from Listing 13-25. You also need to add ServiceStack.Text to the project by running the following command:

Install-Package ServiceStack.Text -Project Discovery.Reccommendations.Followers

Install-Package ServiceStack.Text -Project Discovery.Reccommendations.Followers

清单 13-26 中的代码还依赖于清单 13-27 中的类和以下using语句，这些语句需要在同一个文件中添加：

The code in Listing 13-26 also depends on the classes in Listing 13-27 and the following using statements, which need to be added in the same file:

using ServiceStack.Text;
using System.Xml.Linq;

using ServiceStack.Text;
using System.Xml.Linq;

获取 feed 后，就可以处理各个事件了。清单 13-28 展示了BeganFollowingPollingFeedConsumer的一个示例实现。

After fetching the feed, individual events can then be processed. A demonstrative implementation of this for the BeganFollowingPollingFeedConsumer is shown in Listing 13-28.

清单 13-28 演示了在 feed 消费者中可能看到的通用高级逻辑。首先，从 feed 中获取一批事件，然后选择尚未处理的事件。在某些情况下，如果 feed 需要分页或存档，您可能需要再次使用超媒体发出额外的请求，以定位最后处理的事件。找到未处理的事件后，您可以根据域规则处理每个事件，并更新最后处理的事件的 ID。

Listing 13-28 demonstrates the generic high-level logic you would likely see in a feed consumer. First you fetch a batch of events from the feed, then you select the ones that have not yet been processed. In some cases where feeds are paged or archived, you may need to make additional requests, again using hypermedia, to locate the last event processed. After locating the events that are unprocessed, you then process each one according to your domain rules and update the ID of the last processed event.

您可能想知道在事件处理过程中如何处理错误。基于 REST 的集成不支持有害消息或传递性消息。本章末尾将更详细地介绍这一点。

You may be wondering how errors are handled during the processing of events. With REST-based integration, there is no out-of-the-box support for poison messages or transitive messages. This is covered in a touch more detail toward the end of the chapter.

要完成示例，您需要实现剩余的底层逻辑，即解析来自 feed 的事件。如清单 13-29 和 13-30 所示。您还需要最后一对using语句：

To complete the example, you need to implement the remaining piece of lower-level logic, which parses events from the feed. This is shown in Listings 13-29 and 13-30. You also require a final pair of using statements:

using System.IO;
using System.Xml;

using System.IO;
using System.Xml;

本章的示例到此结束。希望您已经理解了足够的理论，并看到了足够多的示例，从而有信心将 REST 作为项目中有界上下文集成的一种选择。

That wraps up the example for this chapter. Hopefully you’ve understood enough theory and seen enough examples to feel confident about considering REST as an option for bounded context integration on your projects.

本示例剩下的工作就是测试一切是否正常。您可以通过 POST 新的关注者信息来测试，如前所示。留意自动弹出的控制台窗口。您应该会看到类似于图 13.21的输出。您也可以再次直接在浏览器中访问 Atom 提要，查看其中出现的新事件。

All that remains for this example is to test that everything works. You can do that by POSTing new followers, as shown previously. Keep an eye on the console window that automatically pops up. You should see output similar to Figure 13.21. You can also access the Atom feed directly in the browser again to check the new events that appear on it.

维护 REST 应用程序

Maintaining REST Applications

与消息传递系统或任何其他系统一样，应用程序在初始部署后必须提供支持。这可能涉及 API 的版本控制（随着 API 的演进）、系统性能监控，或用于业务决策的指标收集。

As with a messaging or any other system, you have to support the application after it has been initially deployed. This may involve versioning APIs as they evolve, monitoring how the system is performing, or capturing metrics that are used to inform business decisions.

{
    "totalLegs": 5,
    "legsCompleted": 3,
    "currentVesselId":"sst399",
    "nextVesselId":"u223a"
}

{
    "totalLegs": 5,
    "legsCompleted": 3,
    "currentVesselId":"sst399",
    "nextVesselId":"u223a"
}